14 things you need to know about building and launching on iOS 8
Hosted by Funding Circle in the colourful canteen at their City of London headquarters, teams from some of Europe’s brightest startups gathered earlier this month to hear how Shazam, SwiftKey and Big Health fared when they created and launched apps on iOS 8. Here are some of the tips and insights they shared at the meet-up, which was co-hosted by Index.
1. Apple appreciate early adopters.
“We've always been an early adopter,” said Alistair Poolman, senior product manager at music and TV recognition app Shazam. “Apple appreciate those developers that leverage their new functionality early on -- and there are plenty of App Store featuring opportunities that can come of that.”
2. Allow plenty of time for the unknown.
“Apple provides a great deal of information months in advance alongside their beta releases, so you've got time to download the new software and process all the updates,” said Poolman. “However, it’s important to realise that features do change a lot through that time. This is why plenty of preparation and allowing enough time for the unknown is really important.”
3. Make location permissions server-configurable.
With iOS 8, there are now two levels of location permission: ‘While using the app’, when you’re in the app, and ‘Always’, which means [we] can use it when you’re outside the app, said James Hewitt from Shazam’s iOS team. However with the ‘Always’ permission there is a risk that a larger number of users will refuse the app permission, so you need to be careful.
Shazam, for example, has a feature called Auto Shazam, where users can turn on a switch so the app will automatically recognise the music around them, he said. “Users then have an interesting insight into their day, journey or evening by looking at the music they’ve interacted with during that period of time.” For Auto Shazam, the team wanted to use the higher permission level, but decided to make it server-configurable, so that if they noticed a big drop off in users, they could switch to asking for lower-level permission instead. “Fortunately we haven't had to do that yet,” said Hewitt, “but it’s something we’d recommend doing with location permissions.”
4. Widgets & Notifications are development quick wins.
Two new features came out with iOS 8, ‘Today Widgets’ and ‘Actionable Notifications’, which are difficult to business case given they are brand new features on the platform, said Poolman. “So this proposes an important developmental decision: do you focus your resource on one of the other priorities in your roadmap or backlog, or do you have a look at these new features?”
Shazam opted for the latter, because they were development quick wins, which wouldn’t end up being expensive if they turned out to be unsuccessful, he said. “They are also new entry points into the app. There are very limited spots on a user's home screen and many apps won't be there, so if you can get other ties into the OS, that's going to be key to driving traffic. And both widgets and actionable notifications offer that.”
5. Use iTunes Connect early on.
iTunes Connect, said Poolman, is something that most developers leave to the very end before launch, but from the product and marketing side this is a really important tool. “This allows you to set up your storefront and primary entry point for someone getting your application,” he said. “So use it early.”
6. Lock yourselves in a room.
The main challenge faced by personalised technology company SwiftKey centred on looking at what they’d already achieved on Android, then identifying the most important elements and transferring them to iOS 8, said SwiftKey’s Naomi Morton.
“So we basically locked ourselves in a room,” she smiled. “The reason for that was things were constantly changing. We weren’t just building into one new API, we were building -- and building with Apple -- at the same time, so it was very important we were all in the same space and able to shout across to each other, because we had to do it fast.”
7. Work in short sprints.
“We decided to work in very short sprints, because the platform was an entirely new thing for Apple to open, which meant we were finding new problems, then they were finding new problems, then they were fixing things, and we’d be discovering new issues,” Morton explained. “So we worked in weekly sprints to enable us to leave enough time to plan every week.”
8. Be flexible with processes.
As a product manager, you are constantly told you must follow a strict process, and follow it very exactly…neither of which the SwiftKey team did in this case, said Morton. “My advice, here, is look at all the standard processes you should be using and then tailor them to what you’re actually trying to do. We found some rules were way too restrictive, like actually portioning up how long something was going to take didn’t make sense, because it was new, so we didn’t have this knowledge [yet].
“To begin with, we organized tasks by T-shirt sizes: small, medium and large. But by the end, we actually needed to have a stand-up every morning, where everyone chats about what happened the previous day, and that way, we started to get a feel for exactly how long something was going to take.”
9. Beware of platform differences.
The fact that third-party keyboards had long since existed on Android, meant that there were huge expectations, because people were used to building things on Android, on which certain functionality is really easy and certain features are available, Morton explained. “So I spent the first three weeks [of working on iOS 8], having to notify people internally of any differences I found between Android and iOS. There are things that are slightly different between them, or that are done in a different way.”
10. Forge links with Apple.
The SwiftKey team was lucky enough to have quite a few contacts within Apple, ranging from tech to UX to App Store managers (forged during the release of SwiftKey Note), who helped them out along the way, said Morton. “The result of our back and forth -- and meetings -- with Apple, was almost to bring them with us on the journey we were taking of ‘This is new, so how do you think it should work? What’s your intention with this area of functionality?’. Ultimately, they ended up featuring us in quite a few places, which was fantastic.”
11. Factor in memory constraints.
iOS 8 has a “low and strict” memory limit for keyboard extensions, warned another SwiftKey iOS team member, Honza Dvorsky. Whenever you touch the limit, the system kills the memory extension immediately, causing a crash to users, he said.
“The memory size was definitely a bit of an issue for us, at least initially. I spent over a month trying to optimise the memory. We ultimately made a better app because of it, because when you have 40-50 MB with which to do everything, you really have to know your code,” he added.
Big Health (Sleepio).
12. Always have ‘walk away’ ability.
Citing Nik Silver’s thoughts on replatforming, Greg Detre, CTO of digital medicine provider Big Health, advised that whenever you are doing a “gigantic move” -- like rewriting your legacy API – do it gradually. “You should make sure you can keep the old and new running side by side,” he said. “You should also ensure it’s reversible -- you should have walk away ability, which means if you get halfway through and realise it was a terrible plan, you can easily reverse it or at least get some value from what you’ve already built, and focus on the stuff that’s most valuable or most risky first.”
13. Keep doing your QA.
“Always bear in mind that every time a new beta comes out, it could break the demo your CEO is about to give that day,” said Detre. “So make sure you redo your QA every time a beta comes out, because we got bitten by that twice embarrassingly.”
14. Do a ‘pre-mortem’.
Always do a ‘pre-mortem’, Detre also advised. “A pre-mortem is a little bit like a post-mortem, where you evaluate what went wrong, but with a pre-mortem you do it before it’s finished going wrong. So midway through the project, you imagine standing outside the office screaming into the abyss, having missed your deadline, and you ask yourself: ‘How did it come to this? What do we wish we'd done differently? Which features do we wish we'd cut?’ That perspective makes it much easier to make difficult decisions and feature sacrifices.”