Over the last month or so I’ve been spending my days learning Java and Android development. As an iPhone user I find myself trying to make sense of Android apps through the lens of years of iPhone use. I realized that I needed to be a real Android user. Much to the dismay of most people who know me I visited the Google Play store and bought a Nexus 5. After receiving the Nexus I went to AT&T to get a micro-SIM and I made the switch.

Observations

The first surprise was the price. Unlocked, no contract, no carrier commitment: $350. The last time I purchased an unlocked iPhone it set me back $950. Why are Android devices so inexpensive?

The second surprise was the quality of the software experience. I’ve had various Android devices over the years for testing purposes but they all seemed cheap and clunky. The Nexus 5 runs vanilla KitKat and it is years beyond older versions in every way. I liked the lack of manufacturer kludge as well. My Samsung Galaxy S2 testing phone was highly customized by Samsung and felt clunky. Vanilla KitKat comes close to matching iOS 7’s finish in many areas and surpasses it in many others. Gone are the days of Android trailing far behind iOS in functionality and experience. KitKat is polished and mature feeling.

Most of the apps I use on a daily basis, Spotify, Twitter, Facebook, Circa, Pocket, Fliboard, Zite and NPR News are all first class citizens on Android. Aside from a hellish logging-in-to-all-the-things experience my digital life ported over nicely. The Gmail app worked great. Hangouts was mildly confusing but ultimately worked well for texts and instant messaging. The experience also gave me the excuse to move my wife’s calendar and my calendar from iCloud over to Google Calendar. Since we both use Gmail it was something I’d been meaning to do for awhile.

Love

The best feature of Android is the back button. Navigating between apps is seamless. Its hard to explain this feature to an iPhone user. It doesn’t sound that sexy but oh man, it is sexy. The flow of jumping from one app to another and tapping back to jump between apps is such a better flow than the iPhone’s app switching. It just feels more natural and useful.

Another feature of the Nexus that I loved was the screen size. At just under 5” the screen is big and beautiful. The full 1080p screen has room for much more content then an iPhone 5s. I hope the rumors are true about larger iPhones coming this fall.

Google clearly excels at cloud services. The thoroughness and reliability of their offering is impressive. Their services cover almost all possible needs and are available everywhere. The portability of using Google’s services over Apple’s gated ecosystem is attractive. Gmail, Google Drive and Hangouts are as reliable as anything else out there and considerably more reliable than Apple’s several attempts at cloud based services.

Google Now was a nice surprise. It is integrated directly into the OS and is incredibly useful. Being able to configure Google Now along with it’s learned behavior made my experience with the device personal and contextual.

Android has the concept of widgets, small subsets of an app’s features that are installable on the phone’s home screens. The two widgets I actually used displayed the current weather and another that launched a specific Dropbox folder. Due to a great architectural decision in Android it is possible to deep link into apps all the time. Deep linking is a must have feature for future version’s of iOS. The productivity gains from going directly to the area of an app you need are huge.

Hate

While the Android Apps I used had come a long way since they were first introduced some aspects of the experience felt less refined than on iOS. For example, the lack of rubber banding on scrolling lists felt off and unnatural.

The first pain point came when I stopped receiving “texts” from all my iPhone friends. These were of course iMessages and Apple’s servers failed to release my phone number and start sending standard sms texts instead of iMessage. While not a problem caused by Android this drove me insane. I have several Apple products connected to iMessage; my mac book pro, multiple iPads and my iPhone 5s. Turning off iMessage for my phone number did not fix the problem. Apparently I am not the only one who has had to deal with this: iMessage purgatory.

After the whole text/iMessage fiasco (Apple’s fault for sure) the next biggest challenge was visual voicemail. AT&T has an Android App for visual voicemail. Despite a good hour of trying and another hour on the phone with AT&T I never got visual voicemail working. Its amazing how fast certain features become expected. Using a smartphone to call and retreive my voicemails felt antiquated and frustrating. Android users have since told me that Google Voice is the best app to use for visual voicemail. I never tried it unfortunately.

Conclusion

I found the entire experience to be less cohesive than iOS. I’m not sure if the problem is too much choice or if it is just a maturity issue but I didn’t open the box, turn it on and have a smooth, working smart phone. The experience was impressive and the phone was beautiful but somehow the combination of all the parts did not add up to something greater than the whole. Apple consistently nails this.

How long did I use the Nexus 5 as my primary phone? 5 days. I’m back on the iPhone and I don’t miss the Nexus much. I am glad for the experience though. When I work in Android now I have a much clearer idea of what users expect. iOS users and Android users should and do expect a different experience. The interaction is different so our applications should match those expected interactions. Google has done some amazing work in a very short amount of time. Apple has some work to do if they’re going to remain competitive with Android.

On a recent client project we had the need to research the encryption/security features available to iOS applications. This is a modified write-up of our findings. Special thanks to Jay Zeschin @jayzes at Mode Set for editing the original draft I wrote.

There are several layers of security that affect a user’s data when using an iOS app – security at rest on the server, security in transit over the network, and security on the iOS device. Focusing on the iOS device only for now, there are several scenarios that are of primary concern: while a user is actively using the app, while a user not actively using the app, when data is stored on disk, and when data is present in memory (RAM). In addition, there are security concerns inherent in ancillary processes such as backing up a device (via iTunes or iCloud) or migrating data to separate devices (e.g. when a user gets a new phone).

While it is impossible to protect user data 100% in all scenarios, there are a number of options available that provide increasing levels of security and protection. Each additional measure of security has advantages and drawbacks, and comes with some measure of added time and effort during the development process.

1. Built-in Data Protection

Starting with iOS 4, Apple added operating-system level data security provisions and made them available to app developers. In short, if an app developer chooses to make use of these protections and an app user enables a passcode on their device, all data stored to the device by that app is transparently encrypted and protected from unauthorized access by anyone (including the user) when the device is locked, protecting it while at rest. Technically, this is implemented with a tiered system of encrypted keys called keybags, the last of which is based directly off the user’s passcode. When the passcode is entered and the phone is unlocked, all application data is available and unencrypted.

This built-in protection scheme is what Apple makes use of internally for their own apps (such as Mail). It’s a great option and requires very little development time to integrate, so we strongly recommend using it. Any strategy we choose should, at minimum, include this security measure.

Pros:

• Hardware-keyed and transparent encryption of user data
• Follows industry standard practices
• Integrated at the operating-system level
• Architected, developed and supported by Apple

Cons:

• Requires the user to have a passcode enabled on their device to offer any sort of data protection value
• Apps are unable to programmatically ascertain whether a user has enabled a device passcode (a relatively recent change), which prevents apps from being able to prompt users or limit functionality to guarantee that data is protected. See more about this in the “Recommendations” section below.

2. Adding a Second Level of Protection

The two cons of built-in data protection are significant limitations, and due to the low level integration of those built-in protections into the operating system, it is difficult if not impossible to augment them directly. For that reason, it is often necessary to implement additional protection of sensitive data at a higher level. Several industry tested code libraries exist for this purpose, most notably SQLCipher. These libraries encrypt the data contained in the database files before they are written to disk, in contrast to Apple’s approach of encrypting the file itself.

Pros:

• Offers additional protection on top of Apple’s basic security
• Data is encrypted and secure even when the device does not have a passcode
• Ability to customize/control protection and related user interactions within the app

Cons:

• Time consuming to implement, requiring structural changes to the existing data model
• Requires introducing a strategy for encryption key management
• Introduces an overhead for management/maintenance on future feature work

3. Removing Sensitive Data From Memory

When data is actively in-use by an application it is stored in RAM, a volatile physical location on the device. Depending on the specific use case, some kinds of data are created, accessed, and destroyed all solely in RAM. Other data (downloaded images or data from a local database, for example) is read from disk and stored in RAM. Data stored in this way is necessarily unencrypted and inherently temporary – it is created by the device as needed and discarded when the app is no longer running. However, the way that Apple has architected iOS means that applications may continue to run and be resident in memory when they are in the background, sometimes for days or weeks on end. While it would take a much more concentrated hacking effort, it is technically possible to access data belonging to a running app from memory. Securing this data requires purging all sensitive data from memory when a screen is hidden or the application goes into the background – a process that involves a very careful line-by-line audit of an app and how data is created and stored.

Pros:

• Combined with the previous steps, this is the most secure form of data protection
• It is much more difficult to exploit a running application with this level of protection

Cons:

• Extremely time consuming to implement
• Requires close scrutiny of every line of code in the app