Beginning to embark on building my next iOS app, I am taking note to include the correct elements this time around (for my last app, ProgressPic, I forgot some things that would be a pain the the butt to implement now).
I was reading a great post recently about not rebuilding your apps from scratch which inspired me to want to include all of these important elements in my next app, KitPilot.
Localization
I included localization in ProgressPic (albeit this was the first time I had done do so in any app that I build). I thought it would be fun to be able to have the app cater to the Spanish market as well as English. Previously, I was just hard-coding strings into my apps.
Good Resource: https://medium.com/swlh/app-localization-in-swift-ios-swift-guide-baa2c2e4298e
App Analytics
This is where I dropped the ball in my last app. I included FirebaseAnalytics and Crashlytics however I did not take the time to implement my own analytics solution.
I was planning to use Amplitude, but I just never got around to it. Honestly, I did not see the value in having analytics until I saw an internal document at work talking about an A/B test that was run to test two different screens for which one would engage users more.
I guess this is why I’m a developer and not a product manager 🧐
Logging
Logging is important in any software application but especially in a client application such as a mobile apps because the actions taken are not saved to a server log somewhere (as would be the case with a web app).
If a user of your app inquires about a bug how would you track it down without information from the users’ sessions?
A good service I’ve used in the past, although it can be a bit overkill, is NewRelic.
Remote Config
Remote config (such as firebase’s remote config) allows you to configure content in your application via a web server configuration file, which will then modify the experience in a users’ client application.
A good use case for remote config is feature flagging (remotely toggling features on or off in your app), or if there is a bug in a in your app for only certain versions of iOS you can disable the feature for only those versions, or A/B testing different UI views in your app and seeing which version engenders the most engagement.
Source control (Git)
You know I did not include version control in this list because I think it almost goes without saying but using source control is pretty standard business. Even when you start a new iOS project from Xcode there is a checkbox to include source control in the app by default.
The benefits of source control for anyone who might be unaware is the beauty of having a complete history of your applications code every step of the way. It’s like saving your progress in a video game so if the power goes out you don’t lose your place. In the case of source control, you can take snapshots of your code (commits and branches) and build new features on that snapshot without risking your production codebase.
Source control also is very useful in a continuous integration pipeline (pushing code to the “master” branch triggers unit testing and submitting a build to TestPilot for example).
Using a scalable design pattern
There an so many great resources online about design patterns in swift and iOS but the one I lean towards the most is the MVVM and clean architecture patterns.
I’ve come a long way by using MVVM and clean architecture in my apps. Before I was using the standard MVC pattern and if you look at some of my old projects you would definitely see huge, untestable, view controllers 🤨
The benefits of using a proper design patter in your iOS apps is to create a separation of concerns in your applications code to allow for more organization, flexibility, and test-ability. Using a design pattern such as MVVM keeps you from the View Controller of death 😉
Testing
Testing is one component of building apps that I have a love-hate relationship with.
Due to impatience, I would rather keep building features than writing test for the features that I have already build.
This is actually acceptable to me for personal projects but I recognize the huge value of having tests in your app comes into play when you are working in a team…
When tests pass this gives reassurance to people who are unfamiliar with your code that it still works as expected and they did not break anything.
It’s a work in progress for me — I’ll get to those UnitTests in my personal project someday, I promise.
Xcodegen
Xcodegen is basically a config file that defines your application and with one quick command it will generate an xcodeproj for you. Xcodegen was a solution to merge conflicts in xcodeproj files when multiple developers had been working on the same project. I definitely recommend it if you plan to have multiple developers working on your app.
Continuous integration/deployment
Although it takes a bunch of time setting up CI/CD in the beginning, later on CI will save you TONS of time.
A good example of CI is you just pushed a brand new feature branch to git with your latest code for XYZ feature. CI will build your app, run your tests, and can even upload the binary to the App Store and TestFlight. It can be integrated with Github so that branches cannot be merged into the master branch until all tests run successfully.
So that’s all I got. There’s no way this is a fully exhaustive list… It’s just some things that I think are important and I will be using in my future apps.
If you have some suggestions on what you think is important to include in an app from the get-go let me know.
Talk to you soon.
– David
