Before You Switch To iOS Development
These are some nuggets I wish the internet told me about iOS development before I switched from PHP development and built a team of native iOS developers. I’ve got some more but in the interests of not boring you to death I’ve only written what I consider to be the most important of them.
Ah to go back to simpler times. I was told that I should develop for the smaller screen first and this is true in web development as well but I still ignored it. What “they” didn’t say is all of the drawbacks of iPad first which could of been useful at that time.
Unless your entire team of designers and devs are familiar with iPad and Universal apps you’ll end up using too much space which can’t be squashed, doing UX flows that don’t work on iPhone, and have code littered with IF_IPAD.
My advice here is you can do it but prototype and design the iPhone screens at the same time while ensuring that all text fits nicely on an iPhone. Before you decide to do iPad first bare in mind that iPhones are around 90% of the market.
The app store review cycle time is at best for me 5 days, sometimes it’s a lot more. This means everything that needs to be done for release needs to be done at least 5 days before official release. On the flip side this also means you become a little less cavalier with releases because you can’t simply fix it with another release without going through everyone’s favourite process: Expedited Review.
As well as the 5 days there’s always the fear of getting rejected which could add on another 5 days. What do you do? Plan for 10 days? Don’t sweat it.
Plan for five days and follow Apple’s own guidelines and you should be fine. Never forget that the reviewers are humans just like us. They don’t actually hate us and want to destroy our lives.
Plan For Updates
My favourite thing about Apple is that they release to a schedule. They don’t tell you the schedule and they don’t publish the schedule but you can take a good guess at it. WWDC is when they announce new releases so this is when you should be checking out new versions of iOS and planning to adopt new tech. Around September is when they release new phones and versions of iOS.
There is no excuse for getting slated in the store because you didn’t test your app on the newest version of iOS.
Always important and the bane of privacy advocates everywhere but how can I fix that crash if I don’t know where it’s happening or worse yet what if I have no idea it’s happening until the dreaded 1 star review appears? What if there is no crash and a user simply can’t complete a task? There is nothing worse than not being able to reply to those users who slander your 1337 programming skills because their experience went wrong under some random circumstance that you didn’t catch because you didn’t test your app on an iPhone running iOS 8.0.2 with the language set to Japanese and the region set to Ireland using a 12 hour clock in landscape mode.
Crash reporting, and event logging will keep you sane.
As a general rule of thumb proactively fix crashes and if you can achieve 99% crash free users you’re doing great.
You’ll need test devices. Lots of devices. If you support iPad even more devices. This makes the minimum version of iOS you support very important. You can’t buy a new phone with old versions so you need to keep an old one around and put sticky notes on it saying don’t update it. Then you’ll need devices to try out the beta versions with as well.
The adoption rate of iOS is phenomenal though so my advice is only support the latest two releases at a push (less if you can). This means you only need 3 of each device.
Also if you have more than 5 devices get a safe and lock them away. It’s a big expense to replace them all.
Get the fastest hardware you can with the largest possible real estate. Either a kick ass iMac or a MacBook with a giant Thunderbolt display. There is nothing worse than context switching between Xcode, the simulator, requirements, and design. The price of the hardware may make you baulk but the improvements in productivity are quantifiable.
Prototype everything. Everything. I don’t mean those fake prototypes that designers do. The problem with those is the navigation flow is fake and can compensate for issues in your UX. In particular unwind navigation flows.
Write basic prototypes with the flow you intend to use. Then throw that code away and start again. There are two reasons for this. The first is that you quickly realise if something can or can’t be done. The second is that it gives your dev some breathing time to mess around with and to learn new tech, meaning when they actually go to implement that new feature the code will be kick ass (fingers crossed) and (more) bug free.
A great time to do prototypes is when new versions of iOS are released at WWDC.
That’s just some of the things I’d have liked to have known before building a team of native iOS developers from scratch. Hopefully some lost soul dreaming of switching to iOS will find it as useful as I might have back when I was starting out in iOS.