Tag Archives: apps

Advancing Technology by Lying to Developers

Mobile devices have been increasing in screen size, screen resolution, memory, and other capabilities on a continuous basis from the time I got my first Apple Newton MessagePad in 1993. Back then screens were about 336×240 pixels, and each pixel was either on or off — no color. There was a total of 4.625 MB (that’s MEGA bytes) of memory. My first Windows CE device was probably my HP 620 LX in 1998. It was a “clamshell” design with a 640×240 screen and 16 MB of memory.

The thing we knew intuitively from being involved in personal computing since there was such a thing as personal computing was that “change is the status quo”. Our programs never assumed how big the screen was, because we knew our program would need to run next week on a bigger screen, so we wrote our code so that it queried the operating system to ask how big the screen was before dynamically laying out its user interface to fill all available pixels. We never assumed that devices would always be monochromatic, so we wrote our compressed file format to accommodate “words of Christ in red” before they could even be displayed in anything but black on a greenish screen. And even though the entire Bible wouldn’t fit in memory of those first devices, we plowed ahead with the best compression we could manage and a user interface that supported displaying two Bibles simultaneously, knowing that very soon you’d be able to get not just one of our Bibles but two whole Bibles onto the device at the same time.

Fast forward to the iPhone in 2007. When you work for Apple you apparently get big-headed and begin to think you’re among the smartest programmers in the world. Nobody can match your brilliance. Each generation of device you work on is “magical”. It has capabilities and features that nobody could have imagined even six months ago. Features like a more memory and a bigger screen.

Since you couldn’t imagine those features last year, and since you’re God’s gift to technology, you’re positive that nobody else could have imagined those features. So what’s going to happen to all those apps written by people “too dumb to work at Apple” when your new device with a bigger screen comes out? Why, they’ll crash, of course.

Not PocketBible.

You only have to be in this business a week to realize that you can’t hard-code your program to assume a particular screen size. But Apple does this with every single device. Up until iOS 8, we had to prepare a “splash image” to display when the program launched in every possible size and resolution. Currently, that means we have to create launch images in 13 different sizes, one for each iPhone screen size that has ever been shipped, in both portrait and landscape orientation.

Current iOS launch image requirements

Current iOS launch image requirements


If instead they allowed us to manipulate a single image at run-time, we could do all of these with one PNG. But they require us to know every size of every screen we might ever run on (by the way, the image above omits devices prior to the iPhone 4, which would add another half-dozen sizes if they hadn’t already been abandoned by Apple).

This isn’t about managing lots of images. It’s about a philosophy that can’t think past yesterday.

Because of this philosophy, when a bigger screen comes out, Apple either “letterboxes” old apps (putting black bars in the empty space that the program couldn’t possibly imagine would ever be there) or scales them (allowing them to believe the screen is no bigger than last year’s device, then scaling up everything they draw to fill the bigger screen). They believe they are saving developers from having to re-release their apps every time a new device comes out. But in reality, they are requiring every developer to re-release their app to jump through whatever hoop is required to get Apple to stop letterboxing or scaling their apps.

iPhone 6 scaling

Pre-iPhone 6 version of PocketBible on the left gets scaled up. Adding a “launch screen” (which is unrelated to drawing text) tells iOS not to lie to us about the screen size, producing the sharper image on the left with absolutely no changes to PocketBible code!


With iOS 7, there was a special checkbox we had to check to tell the OS that we understood their new semi-transparent user interface elements. With iOS 8, in order to convince iOS not to scale your app (producing blurry text), you have to provide a special, scalable launch image that works on any screen size. (Gee whiz, 2015 and we’re finally recognizing that screens might get bigger in the future! Thanks, Apple!) Until you do that (which requires re-releasing your app), iOS will lie to you about the size of the screen then scale your user interface up to the bigger physical size of the screen, producing blurry text.

Oh, and you still have to provide those 13 launch images for older devices.

The result of this policy of “technical advancement by lying to developers” is that instead of one guy at Apple having to write zero lines of new code, hundreds of thousands of developers have to update and re-release their apps. There would not have been a personal computing revolution in the 80’s and 90’s if Microsoft would have taken this approach. Back then, Microsoft would collect commercial software products and use them for regression testing of new versions of DOS and Windows. After all, you wouldn’t want to do something stupid and break every single app the way Apple does with every release of the iPhone.

This industry used to be exciting. I was like a kid in a candy shop. Technology was changing and we were riding the “bleeding edge”. Now I feel like the only grown up in the room. I want to slap some of these Apple and Google kids around and tell them to shape up.

Fixing Mac OS X 10.7 “Lion”

Apple has a bad habit of hiring kids who have no concept of what came before them. This article helps you undo some of the changes they inflicted on Mac OS X in their attempt to make it “better”.

Reversing the Scrolling Direction

In 10.7, using the MacBook trackpad or the scroll wheel on your mouse will cause you to scroll in the opposite direction than you did previously. Instead of conceptually moving a view port over the document, you are now moving the document. This change was made to accommodate tablets and touch screens, where it seems more natural to use your finger to drag the document. However, rather than making the change apply only to touch screens, they changed all input devices. The result was that the screen appears to scroll backwards if you use a trackpad or scroll wheel.

To fix this, go to the Trackpad pane in System Preferences and uncheck the box for “When using gestures to scroll or navigate, move content in the direction of finger movement”.

Stop Apps from Reopening Previously Open Documents

One of the principles we use in iOS development is that the program should save its state so that when you re-launch it, it will appear as if you never left it. The reason this is essential on mobile devices is that historically they have managed memory themselves rather than depending on the user to close apps they are done with. Since the user never knows if an app has been removed from memory, it would be disconcerting if sometimes the app returned to a default state and sometimes it picks up where you left off.

With both Apple and Microsoft moving toward using their full desktop operating systems on mobile devices, they have begun to take principles that previously applied to small devices with limited resources and applying them to their desktop operating systems even if that doesn’t make sense. On the desktop, the user is the king of memory management. The user opens and closes documents and programs as his task requires. As a partial step toward the integration of mobile and desktop operating systems, the latest version of Mac OS X does two things: First, it saves the state of every app when the app is removed from memory, then restores it when it is re-launched. Second, it remembers what was running when you rebooted your computer, and resumes those programs when it boots up.

The problems introduced by this are myriad, but we can’t expect the little kids at Apple to know that, since for them new is always better and the past is for dead presidents and dinosaurs. For example, if I’m privately reviewing a spreadsheet containing everyone’s salary, then exit Excel, then the next day an employee brings me a spreadsheet for us to review together, when I open Excel the first thing the employee will see is my spreadsheet containing everyone’s confidential salary information.

Disabling this behavior is difficult but not impossible. First, go to System Preferences, select the General pane, and un-check the box for “Restore windows when quitting and re-opening apps”. You’d think this would be enough, but it’s not.

Next, you need to find the folder where Mac OS X saves application state and delete any existing state information. Otherwise, your programs will always restore whatever state was current when you unchecked the box on the Preferences pane. Unfortunately, this folder, which was visible in previous versions of the OS, has been hidden in 10.7. To make it visible, run the Terminal app (Applications > Utilities > Terminal) and enter the following:

chflags nohidden ~/Library/

Now select your Home folder in Finder and you’ll see Library. Open the Library folder, and scroll down to “Saved Application State”. Open that folder and delete everything it contains.

Just to make sure your apps don’t ignore the system preference and save their state anyway, go back to the Library folder, right-click on Saved Application State, select “Get Info”, and set the Sharing & Permissions for your user name to “Read Only”.

How NOT to Stream Live Video from your iPhone

Today I thought it would be cool to stream video of my run to the Internet. I was sure there was an app out there that would do it, and sure enough there is: UStream.

I installed the app and went through the process to set up an account. At the end of entering my data, it said there was already an account for my email address. That was weird; I had never downloaded this app before. I suppose it’s possible I’ve tried installing this program in the past, so I figured I’d ask it to send my password to me and I’d log in to this mysterious, already-existing account.

When I clicked the “forgot my password” link, it asked for my account ID, not my email address. I entered the most likely account ID I may have used in the past, and it told me there was no account for that ID. So I entered a second account ID I sometimes use and sure enough, it said it was sending password reset instructions to me by email.

I waited and waited for an email but it never arrived. So somewhere out there, the person with the account ID “craigr” got a mysterious email asking him to reset his password.

In the meantime I decided to log in with a different email address and was able to set up a new account. I proceeded to the next step, which was to connect my account to Facebook so it could notify my friends when I was broadcasting live video. I got the familiar “connect to Facebook” dialog and entered my Facebook login credentials. Facebook asked for my permission to share all my personal data with UStream, and I agreed. This led to a screen that said, simply, “Success”. There was one and only one button for me to push. It said “Cancel”. I waited and waited but nothing happened. I finally decided to push the Cancel button, and sure enough, it canceled my login.

After trying a couple more times I decided to do an end-run around this stupid process. I went to my iPad and logged into their website using my newly established account. Going into my settings page on the website, I enabled the option to connect to Facebook. Facebook seemed to remember I had given it permission to interact with UStream, so that all went well.

Returning to the iPhone, I exited the application and re-launched it. I tried connecting to Facebook but with no luck. The program simply doesn’t work.

I still think it would be cool to broadcast live during my run and somehow interact with people. UStream is definitely NOT the way to do it.