Last week I finally submitted the next update to Qiozk to the App Store. It has been more than a year since the last update, so it feels great to finally have updated the UI to something I don't have to be ashamed of. Of-course there are more I want to do, but as always, time is not infinite and my users have been waiting long enough.

I have always been on the "native-apps" bandwagon, but when it comes to the UI there are so many more upsides with HTML than native that this time around I went completely web-based for everything that is related to new data. The library (where downloaded magazines are stored) is still native since it doesn't use an internet connection that often. New magazines are published every day, so the clients needs to fetch new data all the time. Magazines are also changed from time to time so it should only cache items rarely. In addition, when you want to read something new, you have to get it from the server, afterwards it can be kept permanently on the device. Basically whenever you want to do something other than read an already downloaded magazine, you need to fetch all those new items (all the text, images, etc). Why not also fetch the UI? One big reason is the offline mode, even tough you can't fetch items while offline, at least displaying the rest of the interface with an offline-message makes the experience much more friendly. The second problem is the perceived startup delay, the user always wants immediate results. I say perceived, since fetching new items and the UI takes roughly the same amount of time as just fetching new items. Having an UI to instantly load, makes the app seem more snappier. The simple solution to both these problems is to separate the HTML from its contents and cache the HTML in the app, and then just fetch new items as a regular single-page web app. Then offline mode is similar to a native UI, and the UI is loaded immediately on startup, giving the user instant feedback.

Pros:

• I can modify the UI without sending the app to Apple for review.
• Bugs or other misstakes can be fixed immediately.
• Every user will always use the latest UI. As soon as they have an internet connection, they will upgrade.
• I can use the same UI on the web, iOS and in the Android app, saving time for building more features instead of replicating the user interfaces.

Cons:

• It has not the same feel as native, not as smooth and the animations look/behave different.
• It takes a lot longer to make an UI in HTML than in cocoa/UIKit, since cocoa is such an amazing framework and HTML/CSS/JS are three bags of hurt. I do however enjoy Javascript immensely, it's just that HTML/CSS is a broken system (more on this in a future post).

This does not mean that every app should have a web-UI. If the data does not change much, or is user-generated, the extra time it takes to create the UI in HTML is probably not worth it. If you only have an iOS and Android version, native could be the better choice (but here you will at least save time). If you have sensitive code that easily breaks, let's say a parser where your users keeps sending new files which can break the parser (like an RSS-feed). Then it would be practical to have this code in Javascript and running it in a WebView. As soon as you get a bug report, you can update the parser to handle this new case. Instant update with no review times and no risk of rejections, to get it through the gatekeepers without any worries. That is worth more than a few bags of hurts.