Tips for Building iOS Apps
Tim Bornholdt
Published on April 14, 2021
Weâve shipped hundreds of apps to the App Store over the last 9 years, and as a result, weâve learned (often the hard way đ) many tricks of the trade when it comes to building iOS apps.
In this post, weâll share some of that knowledge so you can avoid those pitfalls and spend your time making a killer mobile app experience for your users.
Tip #1: Get your DUNS number early.
When you create a developer account with Apple, they ask you whether you are an individual or a business.
If you sign up as an individual, then when a customer views your app in the App Store, the developer of the app is your name.
If you sign up as a business, you likely would prefer to have the name of your company listed as the developer. If this is the case, then Apple requires you to prove that your business actually exists.
The proof comes through Brad and Dunstreet, which is like a credit agency for businesses. They provide you with a unique number for your organization called a DUNS number.
If you already have this number, great, youâre all set. But if you are starting a brand new company, youâll want to apply for this number as soon as possible. Weâve seen D&B issue numbers in as little as a week, and in some cases, as long as six or seven months... which puts quite a bump in your deployment schedule.
Tip #2: Get started on your privacy policy.
We've been in a situation a couple of times where we go to submit the app and everyone's excited and ready to go. And then it's like, Hey, where's the privacy policy? Nothing kills a buzz faster than needing to call your lawyer.
Legally, you have to have a privacy policy. But it's also good to be a good steward of your users' data and tell them how you're going to be using it.
The problem with the privacy policy specifically is, a lot of times, you don't know what data you're collecting until you've built the app. But there are still some boilerplate portions you can get in to get the process started.
If you're lucky, your lawyer will do it right away, but sometimes lawyers just work on lawyer time, so having those legal documents drafted or at least having the conversation started with your attorney is going to save you a lot of time down the road.
Tip #3: Get some iOS hardware for testing.
Most often, when you are just starting to build an app, you use whatever devices you have laying around. iPhones, iPod Touches, and iPads all work great to see how your app looks and works on different screen sizes.
Ultimately a device hooked to a data plan is the best for testing real-life situations, but iOS does come with a few developer options which let you simulate poor network connectivity and other edge case scenarios.
If you have a Mac and are not afraid of getting technical, your development team can teach you how to install the source code on your computer and, using Xcode, run your app on a variety of simulators. These simulators can test many aspects of your app on various screen sizes and operating systems.
Tip #4: Donât install a beta OS on your main device.
Developers and Apple nerds eagerly await WWDC every year. This is the conference where Apple announces the new technologies that will arrive in the fall with the release of their next operating system.
As part of this event, Apple allows developers to download and install beta versions of the next operating system. They very clearly advise that you donât install these beta versions onto devices you use every day. Every year, Twitter lights up with horror stories of problems these mavericks face such as lost data or bricked devices.
Donât be one of those mavericks. Apple calls this beta software for a reason. We recommend that you go out and buy an iPod touch and install beta versions on that device. That way, if anything goes sideways, youâll be thankful that you didnât lose those precious pictures of your kid that you havenât had a chance to backup yet.
Tip #5: Get familiar with App Review Guidelines and the HIG.
Before you even start coding anything, take a look at the App Review Guidelines. It's not that long of a read, and it's good for you to know from a business standpoint what Apple will and will not allow on its store.
Part of what Apple looks for in its review is to make sure that your app conforms to their design guidelines, called the Human Interface Guidelines, or the HIG for short.
The HIG is a robust document that explains how a good app should function on iOS. For example, they explain why buttons are shaped the size they are and why you should incorporate expected paradigms like âpull to refreshâ.
You should try to follow these guidelines not only to get through review, but to also make sure your app provides the best user experience.
Tip #6: Determine how many OSes your product needs to support.
iOS users in general are good about updating to the latest version of iOS.
We typically suggest supporting the current version that's available to the public, and then one previous to that. For example, if you're building an app today in early 2021, we would advise that you support iOS 14 (current version) and iOS 13 (prior version).
However, this advice depends on your specific app. If you are looking to run on extremely old hardware, maybe you need to target back to iOS 10. If you are launching your app in the fall and you want to adopt a brand new feature for the latest OS, maybe youâll stick to that brand new OS.
Itâs good to understand that supporting more legacy OSes will increase your development costs. Thatâs why itâs critical to understand your particular audience and meet them where they are.
As your app grows and matures, you can give yourself a boost in managing your technical debt by continually raising your minimally supported OS and removing code that no longer functions on newer operating systems.
Tip #7: Determine your internal and external testing groups.
The means by which you will get an app onto your phone for testing is through an app called TestFlight. Within your developer account, you can have two different types of users for distributing the TestFlight builds.
The first are âinternal usersâ. The internal group would be your team, like the project manager and whoever else is directly working on this project. As soon as a developer pushes a build to TestFlight, your internal team can see it and review it.
The second are âexternal usersâ, which has a separate review process. An external group would be beta users. Once a build is sent to the internal group and approved, it can be pushed to the external users via a link.
Because internal builds usually have more bugs in them, this allows you to control the process with quality based on testing the app internally first and then sending externally.
Tip #8: Use a good crash reporting tool.
Another cool feature in TestFlight is you can directly send feedback to developers by taking screenshots and leaving annotations of where you encountered bugs. When the app crashes, TestFlight sends that data directly back to the developer.
Your developers will also set up more robust crash reporting software within the app too. The biggest one right now is Firebase, who recently acquired Crashlytics. There are several other crash reporting tools out there, depending on your organizationâs needs.
Itâs important to note that while a developerâs quality assurance process can catch most bugs before shipping, there are certain bugs that canât be found unless they're found at scale, when lots of people are using the app in lots of unanticipated ways.
Once an app is out in the world, you need to be able to figure out how to reproduce those bugs so you can fix them, and thatâs what makes these crash reporting tools so powerful for developers.
Tip #9: Use a task manager tool.
Using a project management tool at the outset can really help make sense of all the chaos.
We at JMG use Trello for managing feature requests, bug reports, QA tests, and development tasks to keep a handle on where everything is.
Other popular task management tools include Asana, Basecamp, and Jira.
Tip #10: Work with a development team you trust.
Apple requires two factor authentication to access your developer portals for App Store Connect. Anytime your developer needs to go in and handle something on App Store Connect, it's going to send you a code, which you then have to provide to your developers in a timely fashion.
As you can imagine, this can cause delays in deployment or writing code if you're not around to give them the code right when they need it.
Something helpful you can do with this process is, if you trust your development team or the project manager, you can make them a user on the account that has access to the two factor authentication so they can authenticate it themselves. This helps speed things up a lot if your development team is working nights or weekends, so they donât have to wait for you to wake up and give them an access code.
If you have a novice team that has never built an iOS app before, they're going to run through a lot of these roadblocks. We can only get over those hurdles with relative ease because we've tripped over them so many times ourselves.
Send them this article (or this podcast episode) or connect with us if you have any questions!
And stay tuned for our next post on Android development tips.
