6 things I learned by publishing an app on the App Store

Here a few takeaways aimed at future me but that you may enjoy as well if you plan on building apps for iOS.

This is Trakx, my simple progress tracking app

During this last holiday season, I set myself to learn a bit more about building iOS apps. It has been a while since I produced anything for a mobile platform and even though I’m quite comfortable with using the Swift language for server-side programming (mostly with Vapor), I haven’t made that many iOS apps with it yet. I have a couple large ones I’m currently working on but to get more confident in using Xcode, design tools like Sketch and go through the whole app submission process, I wanted to build a small app that would let me concentrate on everything except the code itself.

The app: Trakx

As I’m constantly learning new coding skills from many different sources, I wanted something easy to use that would let me have a visual representation of my progress. That’s the basic idea behind the app which I named Trakx (available on the App Store):

• Add a list of objectives.
• For each objective, have a number of steps that need to be completed. For example, if it’s a book to read, add the number of chapters as steps.
• When selecting an objective, give the possibility to increase or decrease the current step.
• For each objective, see a completion percentage.
• Let the user edit an objective title and/or number of steps

And this is basically it. This list was my design document when I started.

Lesson 1: UI design matters & Sketch is awesome

I usually code for the back-end. I don’t do many UI’s and that was my first challenge: making my simple app not only useable but also look good. When I work on web projects, I usually partner with a graphic artist. Creating the necessary assets myself was a challenge. For exemple, here is what Trakx looked like in Sketch before considering UI design:

The unimpressive initial design in Sketch

I picked up the excellent Design+Code book by Meng To and although I haven’t finished reading it yet (that’s one objective I added to my Trakx list, by the way: Design+Code, 57 steps, 16 completed), I can recommend it if you are starting with iOS UI design. Here’s what I came up with after the few chapters I’ve read:

The final version

I’ve also drawn my own buttons as a Sketch learning process:

As a good friend (and excellent developer) puts it, design is what differentiate a “Hello World” from a crafted app. Alright, he was talking about animations and I’m not there yet but you get the idea.

Lesson 2: Moving from Sketch to Xcode took more time than I expected

Although Xcode comes with all the views you could want from UIKit, as soon as you try to do something a bit differently, you’ll have to come up with your own workarounds. This is typically the case if you design your own assets rather than using the stock ones.

Let’s take an example: a simple rounded button. Since iOS 9, the standard iOS UIButton is not rounded anymore. Therefore, there’s some coding involved to achieve this. Here is the result in Xcode:

A rounded button. Not so trivial.

The technique to obtain it is to inherit and extend the UIButton class. Xcode makes use of IBDesignable to display the result in Interface Builder and IBInspectable to provide access to the newly added properties. Here’s my solution:

Now, the new RoundedButton behaves like a standard UIKit view and can be accessed from Xcode:

IBInspectable makes it easy to access your custom properties

The same goes for overriding the height of standard text fields, add a corner radius to a UIView, etc. I am not saying this is difficult but it is something to consider when estimating the time needed to convert a Sketch design to an actual Xcode storyboard scene.

Quick tip: each time you code something generic like this, add it to a Cocoa Touch Framework in order to reuse it in your next projects.

Lesson 3: App Preview is not an instant thing

Now, apps listed in the App Store can feature a video as well as the screenshots. Apple calls this feature “App Preview”. I wanted to give this a try. Once my app was ready to be sent for review, the last thing I needed was to upload the screenshots and the video. The last thing, really. I was surprised to see this:

Whooops… delay!

The lesson here is that you should upload your video to iTunes Connect as soon as possible, especially if you are on a tight schedule.

Lesson 4: There’s a life after your app is done

The App Store requires you to provide a URL to your app website (or, at the minimum, a link to your support page). I hadn’t thought about it prior to working on my app so, before pressing the “Submit for review” button, I made a complete website for Trakx at trakxapp.com. And a Twitter account. And a Facebook page. You should totally follow these two, by the way.

This also can become quite a time-consuming endeavor and it is not directly related to building your app.

Lesson 5: Xcode has a mind of its own

I normally code using text editors. I don’t often use full blown IDEs. Xcode has some quirks but there are three that particularly get on my nerves:

1. It modifies your storyboard from just opening your project in Xcode, thus triggering a Git change.
2. The UINavigationBar contained in a UINavigationController will sometimes lock itself and not allow you to modify its content, like dropping a UIButtonItem in it or set its title, for example. You need to close Xcode and reopen your project, which will sometimes trigger issue 1. It doesn’t even always fix this issue.
3. Autocomplete panics and stops working. You need to close Xcode… well, you get the idea.

Xcode doing some magic by itself

There are parts to Xcode that are great, though. For example, the instruments provided out of the box for profiling an app are far superior and easier to use than their Visual Studio counterparts.

There’s nothing to learn here except that patience is a virtue when working with Xcode. And also, Text from Xcode has it right.

Lesson 6: App Preview can’t show anything else than your app!

This is one more lesson learned about App Preview, the App Store video preview of an app: it can’t show anything that is not your app. In the first version of the video, I was showing Trakx launching from the home screen and this was inserted within a frame displaying an iPhone. Here’s what happened:

The app was rejected the first time because of the preview video

To be fair, had I taken the time to read Apple’s doc on App Preview, I’d have figured it out!

Conclusion

Making iOS apps is fun but I underestimated the work that is not directly related to coding. I’m now hard at work building my next one and I’ll make use of the various things I learned while putting Trakx together.

If you are interested in learning how to code and get certified by one of the world’s top universities, visit exts.epfl.ch.