Changes to iOS and the impact on developers: an example
For some time, I’ve wanted to write an article about how Apple’s iOS updates (the major ones, such as 3 to 4, and 4 to 5) sometimes cause issues for developers. For the record, Apple doesn’t change iOS to cause problems for developers; usually they are incorporating changes with the best-possible end-user experience in mind. At the same time, developers get used to writing code a specific way with specific features, and changes in the operating system (OS) can cause things not to work after a major update.
The app I’d like to use as an example is unrealBook, a PDF music reader that is one of the best apps in that category. It has been designed by a individual who is a gigging musician, family man, and a developer on the side. unrealBook has not been created by a team–it has been crafted by a single person. The developer originally created unrealBook to meet his needs and the needs of his band, but he has also listened to user feedback and suggestions to make the app a real winner for musicians and music educator.
I’ve had the pleasure to interact with this developer frequently over the past two years. I originally wrote a comparison between forScore (another PDF music reader) and unrealBook, and was critical of unrealBook. The developer definitely felt the criticism of the app, as it was his personal project, but he was also willing to write back and open a dialogue about the app. Since that time, I’ve been a beta tester, occasionally offering feedback (when asked) and reporting bugs as I experience them. Over time, the developer was able to add items and tweak the app to make it work as I needed it to work in the field of music education–not that my input alone was directly impacting his decisions–and it was my single favorite PDF music reader for many months.
For the record, I’m not always right about my feedback. I’ve been enjoying a new feature from forScore which integrates a keyboard into the app. The developer of unrealBook reminded me the that he had proposed a keyboard shortly after introducing a pitch feature many months ago, and that I did not think it was an item that would be useful. I was clearly wrong about that (I’m not sure what the other beta testers said)!
At any rate, both the iOS 4 and iOS 5 updates have broken some features in unrealBook when initially released. The developer of unrealBook has worked very hard to address those problems as they developed, but in some cases, a whole new strategy was needed.
In the case of the OS 5 update, iOS 3 and 4 had a feature that allowed any application that used PDF files to draw a page in one pass when the zoom level was greater than 1.0x. With iOS 5, any zoom level greater than 1.0x will draw PDFs in a two-stage process, one blurry, one clear, in a “tiled” manner from bottom right to upper left (exactly the opposite direction needed from a musician reading left to right, top to bottom). Apple suggests that developers follow this process, putting something blurry on the screen first, and then tiling to full clarity. This occurs in apps throughout the iOS environment (such as in Safari, or in slow PDFs in iBooks).
The problem is that until iOS 5, unrealBook was created to draw PDFs in one fast draw at a magnification of 1.26x. This means that after iOS 5, every PDF in unrealBook drew in the two-stage process, which is both slower and again, slightly irritating when reading music as the draw “clarifies” from the wrong direction. The developer of unrealBook was never told by Apple that PDFs should remain at 1.0x, or that drawing at 1.26x would become an issue under iOS 5. It simply became an issue after iOS 5 was released.
1.0x doesn’t sound very different than 1.26x, does it? t wanted to illustrate this, and hopefully my math is correct. I wanted to show an actual image at 1.26x versus 1.0x. I cannot take an image and make it larger with my image software, but I can take an image and make it smaller. This is where my math may be suspect, as image zoom may be calculated in a different way than percentages. But if my math is correct, 1.0x is 79.37% of 1.26x (at 100%). The size difference between 1.26x and 1.0x can be seen below:
In the past, un-cropped music in unrealBook always looked larger than music in forScore. This is probably yet another reason why I liked reading music in unrealBook better than for Score–the music was larger by default! forScore forces compliance to a zoom level of 1.0x, so if you “zoom” in forScore to annotate, you have to zoom back out to turn pages in “normal” mode. You cannot turn a page in forScore while zoomed in (unless you have physically cropped a page or an entire document, which is a permanent, not temporary zoom). In comparison, you can “keep” a zoom level in unrealBook, but it will draw in that two-stage process.
UnrealBook has solved the primary problem of the two-stage draw by causing all new PDF files to draw at 1.0x, unless the user zooms and makes the image greater than 1.0x (a choice that the user makes, but doing so results in a two-stage draw). Again, unrealBook under iOS 3 and iOS 4 drew at 1.26x, so this is a significant change in appearance (see the graphic above). PDF files in unrealBook that existed in the app before iOS 5 will draw at their original zoom (1.26x) and can be updated (zoomed “down” to 1.0x). However, if there was annotation added to those older files (when it was at 1.26x), the annotation will appear smaller (although in proportion to the file) under 1.0x–and if the user wishes to still see the document at 1.26x versus 1.0x, the “tiled draw” will appear.
The developer has written about this situation at the following location:
Additionally, the developer notes that, “unrealBook version 1.6 and above will use the cropbox in PDF files to allow more screen area to be used.” and that “a request has been sent to Apple to restore the one-stage draw.”
The purpose of this article isn’t to blame Apple for causing problems for developers, but it is meant to be informative about how changes in the master OS can require developers to make significant changes to their apps. This article is also meant to help the end-user to have patience while developers work very diligently to solve these issues. On a similar note, forScore (created by a team of developers) had a small blurb on their feedback page informing users of the beta version of iOS 5 that there were problems with forScore using the beta version of iOS 5, and encouraged users NOT to use the app until those problems were solved.
This article is also meant to demonstrate the difference between a single developer and a team of developers. A team can aggressively solve an issue through teamwork, but if you are a gigging musician as your primary job, you have to troubleshoot in your free time–or when you should be sleeping. At $4.99 per app with Apple taking 30% of the income, and paying taxes on the remaining share, most developers aren’t getting rich. Hopefully they are earning enough to justify the continued development of their apps. Users can be highly critical and hurtful in their feedback and comments–and we need to remember that there are people and feelings involved in this highly technical product and process (Negative feedback can affect individuals or teams). There is a place to be truthful and to offer constructive criticism, but some users go WAY beyond truth and constructive criticism. Patience is always a virtue–and my personal advice is to remember that these apps are incredible bargains ($4.99) that the developers continue to improve for free. Be grateful for what we have–as I’ve mentioned many times before, there are no PDF music readers for Android or WebOS.
On a personal note, it has been a pleasure to work with iOS developers, because most developers actually want to correspond about their applications. They want to make their apps better and to have them meet the needs of their users. As the “large” developer companies begin to enter the iOS environment, I hope that they will continue to be as open as many developers have been for their users. On the traditional platforms, interaction with customers has often been a lacking element, whereas many developers have been personally willing to help me track down a problem with a program.