Apple Event 2014 Brings New Devices & Porting to iOS 8

Apple Event 2014 Brings New Devices & Porting to iOS 8 - Lemberg Solutions Blog

Predicting that we’ll have some of our clients returning for an OS 8 upgrade, and that our new apps or ones in the making are bound to support OS 8, we have investigated what it takes to bring your existing and new apps to iPhone 6. This is a brief overview of how the rise of the new iPhone and OS impacts our existing applications and what it takes to bring apps to pastures new.

Let’s assume that there are three types of relative effort for app’s porting to iOS8: S (small), M (medium) and L (large). The table below identifies apps with different UI customisations and, on the other hand, identifies version of iOS for which the app was originally designed.

App’s Development History
UI Types
standard + custom UI implications
custom UI
not ported to 7
ported from 6 to 7
written on 7

“0” (zero) effort is the ideal case of an application built in compliance with all Apple guidelines. But even with “0” effort, it still takes time to review all app’s views and check all functional workflows. In other words, to go through the QA checklist document to verify that everything works.

For the apps Lemberg has originally built, we know exactly how long it takes to carry out regression testing. Results of the tests will define how much of additional scope there is for porting.

The ballpark estimation of porting efforts covers several steps:

  • check all views (sometimes a small fix is required for a screen to open)
  • check primary usage workflows (one or two cases)
  • check all the above on several devices with different screen size. A QA engineer will understand what to review on every next device

This gives us some initial understanding of the scope of porting, no precise information at this step, but something to start with.

Timing ballparks to check your app under new SDK will range from 1 to 16 hours (for the apps we’ve built and, therefore, are familiar with).

Actual Project Checks On New SDK

Lemberg’s iOS team have installed the beta of the new SDK and tried to recompile a couple of existing projects we’ve worked on. Here we provide a brief list of issues discovered in the process. All projects were developed at Lemberg or taken on supported by Lemberg. We identify subjective term “Complexity” to better describe the project’s properties (low, medium or high complexity).

Project A

The most interesting was to check an app built recently for iOS7. The UI/UX of the app was 100% custom. The app we checked has to do with offline graphic content and sharing to social networks. Having launched the project under the new environment, we‘ve found no apparent issues, everything worked smoothly, performance wasn’t corrupted.

ISSUES No issues were found

Project B

App with 100% native UI/UX that deals with data output on lists and works with Core Data.

ISSUES Found an issue with a Search bar. “clear color” for background color doesn’t work, the background becomes black. We had to set search bar style to minimal to fix the bug.

Project C

Another project that was also originally created for iOS7. The primary focus of this app is custom animations and reading the locally stored PDF files.

ISSUES We have found trouble with paths to locally stored PDFs, because of the changes and extension of folder structure in the simulator.

Project D

An app with 100% custom UI and navigation. The app has text content and statistics tables, also Video Playback via native approach.

ISSUES No issues except for the performance of charts. Charts were implemented as native widgets

Project E

his one has a relatively custom UI, and deals with data feeds and location tracking, offline data storage for location change statistics, plus available social login, originally built on iOS7.

ISSUES No issues have been found

Project F

A project with lots of custom widgets, deals with news feeds and calendar information. This app was originally written for iOS 6 and ported to iOS 7 later.

ISSUES Failed to compile as run into problems with custom libraries, UA lib and Flurry for architecture x86_64

Project G

Project with 100% custom UI and navigation, deals with real time ordering of services, real time communication between the client and a customer, location tracking. Originally written for iOS6.

ISSUES Failed to compile because of Location services is not working when built with iOS 8 SDK for iOS 8 (need to use the new Location Services authorization method) Push notifications not working (probably need to use the new registration method) Failed to compile because of troubles with custom libraries, BugshotKit for architecture x86_64

Common Issues

The most obvious issues with porting existing apps to Apple’s OS8 are mostly UI related (although we have discovered no particularly painful stuff with our apps, but that was what happened after release of iOS7, so these have a good chance of emerging for other apps).

A lot more serious would be other types of issues, some of which may be fixed through some kind of workaround, or even reaching out to Apple.

For example, the issue with output of some PDF files on iOS7. Our temporary solution before the release of new OS updates was to change the version of PDF files from 1.6 (Acrobat 7.x) to 1.3 (Acrobat 4.x). However, after the release of iOS7.1 this bug wasn’t observed anymore.

Having spent just a day for OS8 review, we have discovered these most recurring issues with existing apps (chosen randomly from our portfolio):

  • UI/UX (especially for iOS6 apps, for cases of initial violation of Apple guidelines)
  • Compilation issues (related to cases of custom libraries usage)
  • Performance issues (related to custom libraries usage)
  • Used libraries are not recognised by the new OS (custom libraries usage)

The apps most difficult to port to the new OS8 (and the ones that will have poor initial performance on OS8, so are in bad need of porting) are those with any or some of the following features:

  1. Custom navigation
  2. Usage of absolute coordinates for UI implementation
  3. Skipped AutoLayout
  4. Hack tricks for customisation of native controls
  5. Usage of deprecated methods
  6. Usage of out of date third party libraries. Possibly, 3rd party libraries’ authors are already working to resolve these issues.

What should every iOS app owner do as soon as a new Apple OS is released?

Try and launch their app under the new OS naturally, and see how well it performs. With all Apple users upgrading, the level of app success is measured by how well it can keep up with the trends.

If your app has any of the features listed above (custom navigation, native controls hacks - read the full article for the full list;), it will most definitely have performance issues. Reaction time is of essence as always. What happens if the competitors upgrade first? Would some of your users switch to a better performing app with similar functionality? It’s business, so the rule first come, first served applies.

The good news is that, as our latest research into iOS8 has found, there are no such major differences between 7 and 8 iOS versions as there were between iOS6 and iOS7.

This means that if the app has been previously ported to or built for iOS 7 avoiding the features listed under ‘The apps most difficult to port to the new OS8, it will most likely work well on iOS 8.

However, if your app is iOS6-compatible, and you have not bothered to upgrade it to iOS7, this is high time you made that update. Because the market is about to get bombarded with new devices and different screen resolutions compatible with iOS8 and higher. During transition, keep an eye on the UI guideline compliance, stick to Apple’s officially recommended solutions as much as possible, and make sure not to overindulge in workarounds of sorts (in our experience, they work well and save time at first, but fail with any future update).

Questions? Feel free to post them in the comment section below or send us email.