I have always wondered why I am not so efficeint at reading materials on “the web” relative to my skill level in comprehending print or textbooks (digital or otherwise). I think I have a very substantiated hypothesis at this point: typos1. I cannot pretend to be very thorough with things I write, far from it. However, typos have a measurable and disturbing effect on my comprehension while reading a piece of text.

For instance, while reading this:

You’ve already been stuck with this problem for the last 7 hours! You finally you give up and get back to your desk few hours later (after some sleep or a walk with your dog). Voi a la! You found the problem by doing nothing. Actually your mind found the problem!

You finally you give up… gave me an instant pause and I had to go back and reread the sentence before it. While doing that, I slightly lost the gist of what I was thinking from the last few paragraphs. While the brain has great discernment when it comes to identifying words spelled wrong, mine gets startled at grammatical mistakes. I immediately loose my train of thought.

This happens all to often, more so now than before. Up until 2010, most of what I read was either textbooks or newspapers (yes!). They are very thoroughly edited and seldom carry glaring errors of this kind. On the other hand, writing on the web is very sporadic and it shows. I love how open the web is and how anyone with something valuable to say (or not!) can do so, without a lot of hassle. However, apparently my brain still expects rigor and freaks out, ever so little, every single time it encounters an anomaly.

I hate it when that happens.

  1. Typos, here, mean spelling and grammatical errors. 

Material Design, my ¢2

Google’s design guidelines are very good, not in a light way either. Most designers I spoke to today seem very impressed and by just looking at Google’s mockups, it makes me want to make something of that flavor. There are some rough edges but that is to be expected from such a new paradigm. So, does this mean Android is going to be pretty now? Well yes and no.

Stock Android will look a lot better and so will apps from good, thoughtful developers. This still leaves a huge swath of apps behind which will continue to be written in PhoneGap or other horrid tools. It also leaves out carrier apps which are spam-loaded onto every device. There is little hope there.

What would it take to execute this monumental shift in design on Android? For one, better toolchain from Google that affirms first-party tools and reduces (if not eliminates) the need for alternative IDEs. Apple can move mountaints becuse it controls the stack, Google doesn’t. This also comes into play when you look at the hardware that Android runs on. Material Design, like iOS 7, emphasizes GPU intensive animations and fluid transitions. While top-of-the-line Android devices ship with ok graphics, there is a massive swath of Android devices which are being launched/sold today that compare with iPhone 4 in hardware specs and that relic from 2010 cannot play animations!

Should iOS designers, developers, users be worried that Android is now good at design? Non-sense. For one, this is a document, a set of guidelines. Execution is everything and Google still has to prove itself on that front. Second, it is generally good for technology that the most used operating system is finally becoming presentable. It will induce a sense of design sensibility in makers and create a demand for higher quality wares in users. That is good for everybody. Honestly, if Android wasn’t around, there would be nothing pushing iOS.

Oculus Drift

Facebook went ahead and bought Oculus Rift. This adds a few more billions to their Visa bill for this quarter. No big deal.

What I really want to know is what the end game is? Are big companies buying ingenious little startups to lock their place in the future? Seems to me like a state of profound confusion about where things might go. Deep learning? Personal robotics? VR? “Let’s buy a major innovator in every field and let them operate independently. If we ever inch towards a future that inclines towards a particular paradigms, we already have that skunk-works lab in our basement we can start funneling money in.”

This is pathetic. Influential companies like Google and Facebook employ some of the smartest people and are in a position to define that future. They can make it, not stalk it with spaghetti to throw at walls which haven’t been built yet.

How do people buy phones?

HTC might have revealed another great phone this week. Build quality looks incredible, specs excellent, and OS clean.

Joanna Stern quips:

Will anyone care?

Frankly, they won’t! They didn’t last year. So, we know now, specs don’t matter. Build quality doesn’t matter. Even the OS is immaterial given that most other non-Apple phones all run Android. It begs the question, how do people even buy phones anymore? What is the inspiration behind their choice?

Ads? Brand? Random pick?

I am losing interest now.


Yesterday I launched Simbol, an app to quickly find and use symbols and special characters on the iPhone. I developed the app to address one of the most annoying things about writing on iOS: finding symbols. I am a mathematics major and also study quite a lot of physics. Both require a very frequent use of symbols and characters which aren’t found on QWERTY keyboards. OS X has a very handy keyboard and character viewer that carries a big chunk of the Unicode library. However, iOS has nothing that comes even remotely close. I created a library of LaTeX snippets in TextExpander but that mostly went away with iOS 7. As a result, I am practically unable to take notes on iOS in most of my classes.

I wasn’t sure that there were many people, besides myself, who would find something like this useful. However, the response from friends and new users has been great and you all seem to like the app1. I am glad! Looking at most of the user feedback, I believe it would help to know the direction Simbol is headed in.

This brings us to the motive of Simbol: Simbol is intended to be the Keyboard And Character Viewer for iOS. This involves bringing the app on par with OS X. That is an enormous number of entities for the current design to efficiently support. Thus, I am already working on rethinking the workflow. That’s all I can say today.

Simbol is something I created to address one of my pains of writing and working on iOS. It is really great to know that others find it useful. I can’t wait to share what’s in the works!

I would love to hear what you think, or if you have any feature requests. You can always find me on twitter: @gravicle, or email me here.

  1. Gabe at Macdrifter and Viticci at MacStories even reviewed the app! I did not expect that to happen! 

Taming TestFlight

While TestFlight is an incredibly useful service, it has been a bit of a skirmish for me to get around. The workflow can be very convoluted. I am not sure it is my own dense brain or the process is indeed intricate. So, I wanted to write a guide for my own reference and for new developers.

First, here are TestFlight’s guides for getting started:

However there are caveats, from Apple’s as well as TestFlight’s side which make the process a pain in the butt! So, here is the workflow that works for me. This is being written from the perspective of a developer.

  1. Setup
    1. If you don’t have a TF account, create one → TestFlight » Beta Testing On The Fly. If you have a tester account, flip the switch in ‘Account Settings’ to allow access to developer features → TestFlight » Your Account.
    2. Create a team if you don’t have one already. All apps uploaded to a team will be visible to all the team members. However, you can configure access to build granularly, as I discuss in 3.2.
    3. In your Xcode project, add and enable TF SDK → TestFlight » SDK. Follow the instructions that ship in ‘Readme.md’.
  2. Generating and uploading a build
    1. Set the deployment device to iOS Device in Xcode.
    2. Then archive a build. Product » Archive. If the build fails with an error about missing provisioning profile, set the appropriate team profile here: Build Setting » Code Signing » Provisioning Profile. If you set a distribution profile, TF will reject the build.
    3. Once the build is archived, organizer will pop-up: Distribute » Save For Enterprise or Ad Hoc Deployment.
    4. Having generated the IPA, upload it to TF → TestFlight » Dashboard. You can also use their desktop app → TestFlight » Tools.
  3. What devices have access?
    1. TF can read the provisioning profile that is embedded in your uploaded IPA. So, all the devices you have in you provisioning portal at the time of generating the IPA will show up in TF. Those devices which have associated TF accounts appear as testers’ names with device details, others will be just UDIDs.
    2. To see all the devices in the current profile follow these breadcrumbs: Apps » Your App » Build » Permissions (in the left-sidebar). Here you can granularly configure access.
  4. Inviting testers
    1. TF cannot directly add or modify devices in your developer account. However, it does send you a nice email with UDID and other device info from testers which you can use to add devices to the developer portal.
    2. Invite new testers via TF → TestFlight » Add a Teammate. Better than sending emails is just sharing recruitment links. Grab it here → TestFlight » Recruitment
    3. They will receive an email with an invite which they can follow to create a new account and/or install your provisioning profile on their device. Once they do so, you’ll receive an email with their device details. Sometimes, this can take a while; you need to wait this out or ask testers to send you their UDIDs manually[1].
    4. Add the device(s) to provisioning portal → iOS Devices – Apple Developer. You can upload the file(s) TF sent you in the email.
    5. Now, your new testers will show up in TF under Teammate Devices Not On This Profile. Apps will start showing up for new testers but they will be denied installation.
  5. Adding testers to profile
    1. The simplest way to add new testers to a TF profile is to upload a new build after refreshing Xcode[2]. To refresh Xcode: Preferences » Accounts » Select your Apple ID » View Details » Refresh arrow. Now generate a new IPA and upload it to TF. On the Permissions page for your build, check the new devices and voila.. Your testers will now have access (ask them to refresh the TF page in their browser).
    2. If you’re not ready to upload a new build, you can add new testers by updating the profile in TF.
      1. After adding devices in iOS Provisioning Portal, download the updated profile → iOS Provisioning Profiles – Apple Developer.
      2. In TF, on Permissions page: Update Profile » Upload.
      3. Check the new teammates/devices to permit them to install the build.
      4. Ask your testers to refresh TF on their devices and they will be prompted to install a new profile[3]. Once they do, they can access and install your apps!
      5. You won’t have to do this for new builds as they will come embedded with these new devices, as detailed in 5.1.

And that is that. TF is a little overwhelming for new users; I should know! If I missed anything or you need clarification about something, feel free to let me know or ask me @gravicle.

Happy building!

  1. Please ask them to not use apps like this. iOS 7 onwards Apple has blocked access to UDIDs and all these apps can return are advertising identifiers which are useless for distribution purposes. An alternative is to use iTunes → What’s my UDID?.  ↩

  2. You don’t have to. The changes might propagate in time, but it sometimes takes a long time for me. Refreshing ensures that new devices are included in the embedded profile.  ↩

  3. Another reason why this route is sub-optimal.  ↩

Grace Hopper →

The most important thing I’ve accomplished, other than building the compiler, is training young people. They come to me, you know, and say, “Do you think we can do this?” I say, “Try it.” And I back ‘em up. They need that. I keep track of them as they get older and I stir ‘em up at intervals so they don’t forget to take chances.”

-Grace Hopper

Custom stylesheets on iOS

Today Caltech published the third volume of The Feynman Lectures making me jump all around, not quite unlike when the first volume became available. Having bought an iPad Air and loving it very much, I use it for most of my reading and studying. Feynman lectures looked quite unappealing on the iPad curtesy of the persistent “Buy Now” menu floating in the right-top corner and the tiny font size. To rectify this, I started looking for a way to load custom stylesheets is Safari on the iPad. I tried using Provisioning Profiles but could not figure how to make them work. Then, I stumbled across this tutorial on Juicy Studio detailing the process of creating an accessibility stylesheet bookmarklet. It basically solved the issue for me. Here is a page from the HTML version of The Feynman Lectures before and after.

How to do it yourselves?

  • Create a stylesheet, upload it to your hosting account and grab a direct link to the .css file.
  • Paste the link in place of STYLESHEET-LINK-HERE in the following JS


  • Create a bookmarklet with the given code. If you need help with this, here is a helpful video; except that you’ll erase the URL and paste the JS we just edited instead of editing the URL.
  • Place the bookmarklets in “Bookmarks”, i.e. on the top level. This will allow you quick access.

Here is the bookmarklet I created for Feynman Lectures.


Here is another with dark mode!


Here is one that I adapted from the Beautipedia Safari Extension. It makes Wikipedia a bit better than the “Reader” view on the iPad and you don’t even have to go to another app.


Before and after shots:


iOS 7 and Apple apps engineered for iOS 7 are not “simplified” over their older counterparts. Instead they have be redesigned for a different platform, one that can scale. iOS was created at a time when touch-computing was mostly unheard of and apps could afford to be much simpler. However, that time has passed and Apple is building a platform for the future where touch is ubiquitous and interface is nothing but cruft around information and hence, must be minimized. Apps are already running on incredibly powerful and unbelievably efficient architectures like the 64bit A7 SoC. These apps need to grow and scale much further into becoming standalone solutions instead of a complement to powerful desktop apps. Ironically, desktop apps now need to be complimentary and follow along as users move to touch computing. You cannot go on piling things on top of architectures that were conceived with different goals or you get the likes of Windows 8 and MS office. When features are added to apps beyond the initial plan, they inevitably loose simplicity as those things must be jammed in into an interface that wasn’t designed to support all those features. You cannot steer or “adapt” design. You need to restart, from scratch.

Make things as simple as possible, but not simpler.

That’s what Apple tends to do with these apps. These aren’t iOS7-ports or re-skinning efforts. iWork workflow has been completely rethought to work for users who are adopting touch as their primary medium. What is happening is that Apple is designing a content aware interface that can accommodate far more features than the old crufty one. It’s making them scalable for a future where touch, gestures and content-aware interfaces will be the norm. When redoing enormous apps in this fashion, one has to prioritize. All the features will never make it in the first cut or the platform won’t materialize until it is too late.

So, what you got wrong is this: the process isn’t to strip down features to make things simpler, rather to restart and create a platform where far more features and far more powerful functionality can be presented in a much more intuitive and accessible fashion. First step in the process is restarting from scratch and with constraints in mind, one can understand why these apps appear watered-down. Feature-loss is a temporary but practically inevitable outcome of such a process. And a process like this is the only way to ensure relevance as computing moves further closer into the human realm.

The cause isn’t a desire to simplify for it’s own sake and the effect isn’t stripped-down apps. The cause is the start of a new era in computing and the effect is apps which are much more flexible, powerful and scalable. This intermediate stage is just a temporary side-effect.

I’ll say, these are growing pains. Stop whining.