Wednesday, February 3, 2021

SwiftUI + XCode: Best iOS Development Environment

 As a new startup, we had to make lots of decisions.  Sometimes we made good ones, sometimes we made bad ones.  We had to learn a lot along the way just to get our app in the app store.  Coming into this, none of us had experience developing in Swift.  We knew we wanted to target iOS.  Anecdotal knowledge is that if you're going to make money off your app, Apple's app store is where the money is.   According to one estimate, Apple takes in $72.3 billion a year in app store revenue.  We knew we wanted to go there first.  An Android app might be down the road, but as a startup with limited resources, we have to prioritize based on immediate returns.  

So the first choice we had to make with launching our app was:

What Language and UI Framework to Use

The choices as we saw them were:

Native iOS:

Cross Platform:

But what we found out as we did our research was that Swift can actually take two flavors, so different they might as well be different platforms:

SwiftUI Frameworks:

The rest of this post will walk you through our thinking as we made our decisions.  Remember, as you launch your own app, you will have to make your own decisions that are right for you.  Just because we went one way doesn't mean that it won't make sense for you, coming from your own experiences, shouldn't make a different one.

With that out of the way, let's dig in!

Native iOS:

Objective C

What is it:  Objective C has been the workhorse of Apple development going back to even before the iPhone.  It has it's roots in 1970's technology, being an object oriented extension to the venerable C programming language.  Prior to 2014, all iOS apps were written in it.  And in fact many Apple libraries for iOS development are still written in objective C.

How did we decide: No.

Why:  None of us were experienced with Objective C.  Most of us have a dislike for object oriented programming from too many years of writing Java.  The handwriting is on the wall that Objective C is not the future for iOS app development.  This was a no-brainer for us.  No real benefits to launching a new app in 2021 with Objective C, limited lifespan for it to be supported. Next?

Why you might decide differently:  if you have extensive Objective C experience. If you have an existing tool-kit of libraries in Objective C you've built up from other apps.  If you're old and cranky. ;)


What is it: Swift is Apple's new programming language, released in 2014.  It's still generally in the C family of languages, but without the decades of baggage that Objective C carried with it.  It looked clean, relatively enjoyable

How did we decide: Maybe

Why: none of us were experienced with Swift. But it looked well documented, widely used, relatively clean and enjoyable.  Clearly the future that Apple intends to be investing in.  Also, due to some of the hooks that Apple has put around publishing to the App Store, it seemed likely at some point we would have to learn at least minimal Swift + XCode (Apple's IDE for developing apps), even if we went with a cross-platform solution.  This was a definite maybe.

Cross Platform: Xamarin

What is it: Formerly open source, now Microsoft environment for developing cross platform apps using MS technologies. Especially C#.

How did we decide: No.

Why: It was tempting to choose a cross platform toolkit, in case we ever wanted to launch to other platforms (like Android).  But.. developing in C# wasn't attractive.  Having to do most development in one tool (Visual Studio) and then switch over to Apple's suite of tools to build/deploy/code sign wasn't attractive.  If you're a  hard core C# developer who doesn't want to learn a new language, it might make a lot of sense.  Or if you're an experienced iOS developer who already knows the ins and outs of working with Apple's environment with the XCode suite, and you want to target cross platform, then it might make sense.  For us, learning two vertical stack environments (Visual Studio and Xcode), having to troubleshoot issues across both, while being stuck in C#/.Net/Visual Studio land, none of which are our favorite technologies, was a quick no.  

Why you might decide differently: No judgement on anyone who comes from that world.  Arguing programming languages is like arguing Picasso vs Monet.  There's no right answer. Whatever works for you best is good with us.  If you have ex

Cross Platform: RunRev Livecode

What is it: a visual development tool some of us had experience with. Some might call it a spiritual successor to Apple's 1980's Hypercard, which some of us had fond memories of.  It employs a similar stack based metaphor to Hypercard. It promises rapid development with minimal coding.  And it looks like fun!

How did we decide: No.

Why: we have too much experience programming.  When it came down to it, all development involves troubleshooting. Generally speaking, the less time you spend troubleshooting and the more time you spend being "productive," the happier you are as a developer.  Our natural inclination as a team was that it's more fun running in a text based environment (think "type this") rather than a GUI environment (think "click here").  Ultimately, we wanted to sign up for the type of programming where we can do something like 

  • "print(value)"
 as opposed to 
  • "click this menu. Then this. You should see a box that looks like this. Click this. Type in "value""

Why you might consider differently: if you don't have a lot of experience programming. If you want to launch something really simple really fast.  If you enjoyed HyperCard.

Cross Platform: HTML5 (e.g. ReactNative)

What is it: the lingua franca of the Internet. If you're connecting to a web site, chances are it's serving up web pages in HTML5 powered by Javascript.  Obviously, very powerful, very cross platform, very large communities.  

How did we decide: No.

Why: for similar reasons to the Xamarin decision.  None of us particularly enjoy web development.  It's got a lot of clunkiness from the past 25 years.  Javascript is not our favorite language.  But mostly we didn't want to have to learn how to deploy code in the XCode environment but write it in an HTML 5 environment.  Maybe next app we will go this route, now that we have native iOS development under our belts and can (mostly) troubleshoot issues that arise in XCode.

Why you might consider differently: if you only know web development.  If having a single codebase for iOS/Android/Web is important for you *and* you know the ins and outs of publishing native apps already.


Ultimately we decided to build a native app with Swift.  Now that we have launched our app, we feel confident we made the right decision for us.  We have a clean code base. We spend much less time fighting 3rd party libraries than we ever have (Swift has most of the tools needed built in).  XCode is *pretty* good about finding coding issues at compile time, especially due to our choices about SwiftUI vs UIKit.

If you liked this article, you could take a look at our app in the app store:

Why We Didn't Use AWS Lambda: EC2 Fits Better (For Our Golang App)

This is going to generate some hate.  But technology is complicated.  You *will* be able slice the numbers differently with different assump...