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.

APFS in Detail

In June of 2016, Apple announced the file system that would be replacing HFS+: Apple File System (APFS). Adam Leventhal wrote a detailed series of posts about what’s coming in the new file system:

Apple announced a new file system that will make its way into all of its OS variants (macOS, tvOS, iOS, watchOS) in the coming years. Media coverage to this point has been mostly breathless elongations of Apple’s developer documentation. With a dearth of detail I decided to attend the presentation and Q&A with the APFS team at WWDC. Dominic Giampaolo and Eric Tamura, two members of the APFS team, gave an overview to a packed room; along with other members of the team, they patiently answered questions later in the day. With those data points and some first hand usage I wanted to provide an overview and analysis both as a user of Apple-ecosystem products and as a long-time operating system and file system developer.

Beyond losing the mass of technical debt accumulated in HFS+, the feature that appeals to me most is encryption becoming a first class citizen. This will be seamless to the end user, but provide for greater security going forward.

Multi-key encryption is particularly relevant for portables where all data might be encrypted, but unlocking your phone provides access to an additional key and therefore additional data.


APFS (apparently) supports constant time cryptographic file system erase, called “effaceable” in the diskutil output. This presumably builds a secret key that cannot be extracted from APFS and encrypts the file system with it. A secure erase then need only delete the key rather than needing to scramble and re-scramble the full disk to ensure total eradication.

Quite interestingly, APFS will be adding I/O QoS:

APFS also focuses on latency; Apple’s number one goal is to avoid the beachball of doom. APFS addresses this with I/O QoS (quality of service) to prioritize accesses that are immediately visible to the user over background activity that doesn’t have the same time-constraints. This is inarguably a benefit to users and a sophisticated file system capability.

I’m curious to see how much impact this will have in the real world, but conceptually it makes a lot of sense.

I also learned from Adam’s posts that if you want to experiment with prerelease APFS now, there is a bit of humor in avoiding interactive confirmation of the risks associated:

[diskutil] prompts you for interactive confirmation of the destructive power of APFS unless this is added to the command-line: -IHaveBeenWarnedThatAPFSIsPreReleaseAndThatIMayLoseData; I’m not making this up

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. ↩︎

More Back Button Confusion

In December I wrote about iOS Back Button Confusion, outlining how having multiple back buttons on the same screen in iOS creates user mistakes or slowdowns as they determine which button they should use. I recently noticed the same issue with my RSS reader of choice, NetNewsWire (which is an outstanding app for reading RSS feeds on the desktop).

In similar fashion to the iOS apps, NetNewsWire has an embedded browser for viewing links. Thus, it also requires having two back buttons: one to exit the browser and one for going backwards in the browser history.

With NetNewsWire, as with iOS, I find myself exiting the embedded browser when I intended to go backwards in the browser history. This causes a small amount of frustration which adds up to a poor user experience over time.

My proposed solution still stands, as the dynamics of the problem have not changed between touch screen and pointer input methods: provide a way for the user to “undo” the act of closing the browser. For a deeper explanation of not only the solution, but the problem, take a look at the previous post.

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.

Apple Forgot About Fitts' Law

I have this quirk when I’m reading something on my computer (website, PDF document, etc) that I want to keep my mouse pointer visible so I easily know where it is when I want it, but I don’t want it in the content area itself obscuring what I’m trying to read. The margin of the content is the perfect place for this and that is generally where I leave my mouse when reading.

The other day I opened 5 PDF documents in the same Preview window to read, putting that window into Lion’s handy full-screen mode.

When I went to place my pointer in the left margin of this preview window, however, it wound up hitting the left edge of the screen causing a nifty navigation pane to slide out. I thought to myself “Cool!” and took a mental note for later when I had to switch between the PDF’s.

I was then putting my pointer back in the left margin, being cautious not to hit the edge, when the pane appeared again. This had me very confused and after a few seconds of experimenting I found out that a 40 pixel column along the left edge of the screen (give or take a few pixels) is the trigger area for the pane — not the edge of the screen itself.

This design goes directly against Fitts’ Law. If you don’t know what Fitts’ Law is, I recommend taking a look at the Wikipedia entry (Success and Implications section) for a quick summary. I want to draw attention to one point in particular from there:

Edges and corners of the computer monitor (e.g., the location of the Start button in Microsoft Windows and the menus and Dock of Mac OS X) are particularly easy to acquire with a mouse, touchpad or trackball because the pointer remains at the screen edge regardless of how much further the mouse is moved, thus can be considered as having infinite width.

This means making the trigger extend inside the edge of the window is unnecessary due to the infinite depth this pane comes out of. This is due to the fact that once I know the left side of the screen activates this pane, I am not going to carefully place my pointer there, I’m going to “throw” it left, letting it hit the edge (as I do now). This is a similar action to a person showing a hidden Task Bar (Windows) or Dock (Mac OS).

The only reason I can think of for Apple extending the trigger area into the content is to increase discoverability — a person might be more likely to move their pointer near the edge of the screen than actually hit it. Also, unlike the Windows Task Bar and Mac OS Dock which are visible by default, there is no indication that this pane even exists until you activate it. However, this design comes with a major consequence beyond the annoyance for my quirky mouse-placement ways: if there is ever content under that trigger area, it is inaccessible for annotation or selection (despite the margin being prime real estate for annotations)1.

I have high respect for Apple’s design and execution in their software and hardware, but I believe something was overlooked here, or I am not seeing a use-case that this design is the solution for.

  1. Note that the content can still be accessed/annotated by coming out of full-screen, however I don’t believe Apple’s intention with full-screen apps was to have an app’s functionality restricted to support it. ↩︎