Public Service Announcement: You Should Not Force Quit Apps on iOS or Android

John Gruber at Daring Fireball has the definitive post on why you shouldn’t force quit apps on your iOS device (double-pressing the home button and swiping them away):

The single biggest misconception about iOS is that it’s good digital hygiene to force quit apps that you aren’t using. The idea is that apps in the background are locking up unnecessary RAM and consuming unnecessary CPU cycles, thus hurting performance and wasting battery life.

That’s not how iOS works. ...[U]nfreezing a frozen app takes up way less CPU (and energy) than relaunching an app that had been force quit. Not only does force quitting your apps not help, it actually hurts. Your battery life will be worse and it will take much longer to switch apps if you force quit apps in the background.

The only reason you should force quit an app is if it is misbehaving, such as not responding. All of this reasoning and advice applies equally to Android, which operates in a similar way.

If you force quit apps to keep the app-switcher clean, know that you are hurting your phone’s battery life and your experience. At the time of writing there is no alternative way to keep the app switcher clean.

Star Shield 6

A previous coworker has moved into independent game development and has released a new game: Star Shield 6.

I’ve had it on my phone for over a month now and it’s a lot of fun. It requires more thought than first meets the eye, yet games are fast enough to play on the go. It’s even free!

Go get it on your phone.

iOS Tip: Force Quitting Apps

I was having an issue with the App Store on my iPhone and went in search of a solution. One possible solution called for force quitting the app, but in a way I had never heard of before:

...hold power until the slide to power off slider appears, then hold home until the app quits...

Lo and behold, it worked! This is something to try if you are having problems with an app and swiping it away in the app switcher isn’t working.

Consistently Connect iPhone to Mac Over Bluetooth

For the past few months I’ve been using an application called Type2Phone which allows me to use my Macbook keyboard to type on my iPhone. It works very well, using bluetooth for the connection and makes sending texts and instant messages (MSN, GoogleTalk) far faster on the iPhone. Type2Phone has been the first and only reason I’ve ever had to connect my iPhone to my Macbook over Bluetooth.

Since I started using it, however, I had major issues with connecting my phone to my laptop over bluetooth (note that this is an issue with iOS and/or OS X, not with Type2Phone). Once the devices were paired, trying to connect them would often result in errors such as:

  • “Macbook not within range.”
  • “Macbook is not a supported device.”1

Finally, after far too much frustration, I believe I know how to connect my iPhone and Macbook consistently and it’s quite simple:

Have Type2Phone2 running when you try to connect the devices.

That’s it.

Since I’ve started doing this I haven’t seen any errors and using Type2Phone has become a far more enjoyable experience.


  1. This resulted in a single option to clear the message: Forget Device. Now the pairing was lost and I had to start from scratch. ↩︎

  2. Presumably this fix would work with any program that is actively trying to use Bluetooth open, however I am unable to test that hypothesis as I have no other apps on my computer that utilize bluetooth. ↩︎

On Taking Notes

Being a university student, I have taken a lot of notes for my courses. I have not, however, been able to find a method for taking notes that satisfies my desire to use my computer as much as possible, while giving me the flexibility and speed I need when taking notes. Here I have documented the process I have gone through so far in switching to a digital notes system for university.

Let’s first look at the three key reasons why I want to use a computer to take my notes:

  1. I find typing is far faster than hand-writing, especially when having to copy off of a blackboard or PowerPoint slides.
  2. Digital organization is far easier and more expandable than paper organization - I have no qualms about keeping schoolwork from high school that I did on my computer; all paper documents, however, have found their way to the trash.
  3. I’m a geek. I love my computer and love spending time on it; adding yet another place that I can do so productively is always welcome!

Here are my requirements for an ideal note-taking system:

  1. Diagrams - I should be able to easily and accurately reproduce ad hoc diagrams that drawn by the professor (if applicable to the course).
  2. Random characters, formulas and numbers - Being in engineering, I’ve had to write down many formulas and Greek characters that are often very complex (if applicable to the course).
  3. Organized - My notes should be easily and effortlessly organized, allowing quick reference when needed.
  4. Speed - I need to be able to keep up with professors as they move through powerpoint slides or write on the blackboard at near the speed of sound.
  5. Accuracy - While moving at the speed mentioned above, I need to be fairly accurate with my spelling and 100% accurate with any formulas or numbers.
  6. Portability - I should be able to access my notes easily since you never know when a study session with friends might crop up. In the case of digital notes, this access might happen on a device that I do not own (e.g. a university-owned computer)

It can quickly be seen that my reasons for wanting to use a computer deal with requirements 3 and 4 beautifully; better than a traditional system does. How about the rest though?

In the past I had briefly tried Microsoft Word, only to find it was too bloated for my needs; the extra UI associated with making the notes look like a physical notebook detracted from the notes themselves. Also, my notes were not portable being saved in the DOCX format.

I then remembered TextEdit. It has an extraordinarily simple UI and saves plain-text documents for portability. That was all I needed to give it a try. I developed a simple folder structure for organizing the notes, University/Notes/[Course]/[YYYY]-[MM]-[DD].txt, where [YYYY] would be replaced with the year those notes were taken and so forth.

To allow for easy access, I was already storing my “University” folder in my DropBox so naturally my notes were stored there as well. To allow access on the go, I came across PlainText for my iPhone. This beautifully simple app does one thing and does it very well: text editing on iOS while syncing with DropBox.

The first day I started taking notes with TextEdit, I was surprised at just how fast and accurately I was able to type. This isn’t myself gloating, rather it was the effect of systemwide auto-correct implemented in Mac OS X Lion. Having its roots in iOS, it is far more aggressive than what can be found in Microsoft Word or other word processors. This left me with little cleanup to do after a notes session.

Before classes started I knew diagrams would present a major issue - how do you draw with a keyboard? To deal with this, at the beginning of the semester I took notes using TextEdit for as long as I could before encountering an important diagram, at which point I switched to using a traditional notebook for that course. If there weren’t any diagrams, then TextEdit remained.

The other major issue with TextEdit would have been random characters and formulas. As far as I know, there is no easy way to find and enter large numbers of random characters on computers today (though they do have them in the characters menu).1 I’m far enough into my degree that I no longer have any math or physics courses, however in 1st and 2nd year this alone would have killed any dreams of utilizing a digital system.

So in summary, my system with TextEdit handily takes care of 4 requirements: speed, accuracy, organization and portability.

I used this system for two of my five courses last semester (the others had diagrams and/or characters and formulas) and it worked very well. I took more detailed notes while improving my typing speed and accuracy due to the extra practice.

This semester, I am utilizing Markdown, Byword and Marked to help with formatting my notes (and therefore improving upon my organization) while keeping them extremely portable. On my iPhone, I’m currently using Nocs for viewing and editing Markdown since it is free, however if I find I’m doing this often enough (both for notes and blog posts) I will purchase Elements which I find more visually appealing.

I have yet to find the perfect digital note-taking system that can seamlessly handle diagrams and random characters, though my roommate is currently trying a bunch of apps for his iPad that look promising when using a stylus. I truly believe that tablet computing will be the future of note-taking at school since a keyboard is too limiting, though I cannot justify the cost of an iPad to try it myself.


  1. Latex could be better here, though I do not use it enough to justify learning the syntax for all of the different characters. Also, I find the raw syntax unpleasant to read making it not very portable. ↩︎

Misconceptions About iOS Multitasking

Fraser Speirs posted a very necessary explanation about how iOS background applications work in an attempt to stop incorrect information from being spread.

It is well worth the read and I agree with almost all of his points, except the following statement that he makes a couple of times in the post:

The user never has to manage background tasks on iOS.

While this should be true, I, along with many of my friends and family with iOS devices, have not found this to be the case. If a user let’s the recently used app list grow uncontrolled, it noticeably slows down the device.

This is because an app in the recently used app list may or may not be consuming memory or CPU time (following the rules outlined by Speirs), but if an app is not in that list, guaranteed it is not consuming memory or CPU time. This means removing an app from the list is a method for forcefully freeing memory (or killing the app) and therefore speeding up the device.

As for why iOS noticeably slows down when it needs more memory, but seemingly doesn’t free up what it needs automatically, I don’t know what the reasoning behind that is. Perhaps the algorithm is not aggressive enough on freeing memory, trying too hard to leave apps alone?

The best example of this problem that I’ve seen was when I was in an Apple store and briefly tried out the demo 3Gs (running iOS 5) to find that it was barely usable; when I tried to type out a search on the spotlight screen, the keyboard “hung” with a key depressed for about 5 seconds and all animations were extremely jarring.

Surprised by how slow and unresponsive the phone was, I went into the recently used app list and cleared it out. Removing the first few apps was slow (taps felt unresponsive, animations jarring), but then everything sped up and felt back to normal. Going back to the Spotlight screen and typing again was a bit slower than on my iPhone 4, but very usable, and the animations were quite smooth now.

In addition, usually over once per day I’ve noticed the animations getting slightly choppy and apps becoming less responsive than normal on my iPhone 4. Clearing my recently used app list has always returned the speed and responsiveness that I’m used to with iOS.

I still recommend users clear out their recently used app list whenever they notice their device becoming sluggish as I know from experience that it works to speed up the device.

iOS Back Button Confusion

Since I purchased my iPhone in September, I’ve had a consistent issue that is prevalent in many iOS apps. While small, it is a source of frustration nonetheless. My issue: back button confusion with embedded, in-app browsers.

Let me explain what I mean.

When a link is opened, many apps utilize an embedded web browser to display the web page instead of exiting to Safari (e.g. tapping a link in a tweet in the Twitter app). Upon opening, a traditional “app” back button is placed in the top left (let’s call this the “app back button”) which exits the browser to the screen where the link was tapped. The browser also gets it’s own back button for going backwards in the web browsing history (let’s call this the “browser back button”) placed at the bottom of the screen. This results in two back buttons on the same screen.

While this design is functional, having multiple back buttons on the same screen means I have to choose which one to use: do I want to go back in the app or browser history. While this is a simple decision that makes sense after conscious thought, it doesn’t feel natural. Since I wasn’t in a browser to begin with (remember, I tapped a link in an app), the website feels like an extension of that app and therefore I instinctually reach for the app back button, regardless of whether I wanted to go back in the app or the browser history. If I wanted to go back in the browser history, then I’ve made a mistake. This results in the browsing history being lost with no way to easily undo it; the only way to get back to the last web page is following all of the links again which is both annoying and takes time.

I’ve thought of two possible solutions to this problem (though I know there are far more out there) which I believe would fit nicely with the existing UI paradigms in iOS, and solve the problem explained above.

  1. A single back button
  2. The ability to undo exiting the browser

A Single Back Button

This solution would remove the confusion by having the app back button as the only back button; the browser back button wouldn’t exist. This button would go back through your web history until the first web page, then exit the browser back to the app. There is a major flaw, though; repeatedly tapping the back button could take too long if you’ve built up a history larger than a few pages in that browsing session (not unusual, especially for power users).

The Ability to Undo

This option would give the user a method to undo their action of exiting the browser, returning them to where they were before they tapped the wrong button.

To accomplish this, I propose that tapping the original link in the app immediately after exiting the browser would return the user to the same web page, with the browsing history restored. If, however, you tap another link or change screens in the app, that browsing session would be lost.

An example scenario for this solution would consist of the following steps:

  1. Tap a link to an article in a tweet
  2. Embedded browser opens the link in-app
  3. Tap a link in that article to read supporting information
  4. Want to return to the original article to continue reading, but accidentally tap app back button
  5. Returned to the tweet and realizing the mistake, quickly tap again on the link to the article
  6. Embedded browser opens to the supporting information, not the article, with the browsing history restored
  7. Tap on the back button for browser history to return to the original article and continue reading

I believe this behaviour would feel very natural to users and is similar in concept to fast app switching since state is being restored.