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.

App Story with Vic Hudson

This week I was on Vic Hudson’s new App Story podcast. It was a lot of fun!
App Story is where Vic interviews indie developers about their apps and how they came to be. A must subscribe!

Episode 2: Simbol
iTunes: App Story


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 .

  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:

  • TestFlight | Getting started as a Developer
  • TestFlight | Getting started as a Tester

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.

Thoughts on paid upgrades

This week one of my most used apps, Tweetbot, was updated for iOS 7. It wasn’t just updated but launched as a brand-new app with a price-tag of $2.99. In the absence of a system for offering upgraded apps to existing customers at a discounted price, deemed upgrade-pricing, this is a route a lot of developers are taking. So did Clear when it was updated for iOS 7 and offered as a universal binary. So did 1Password 4. So did Screens.

When Clear was updated, it brought on a furor of criticism for the developers, Realmac Software, a small indie shop. So much so that they retracted and decided to continue developing the older app while offering the new universal app under a different name, Clear+. This was hailed as a specimen of collective shame on the part of AppStore customers. However, I believe that the Clear scene was more about Clear itself than about the “shameful resistance of users in supporting an indie developer”. Here is Clear for iPhone before (left) and after (right) the update.


Here are the release notes for the update from Macrumors.

List Peek – Pull down with two fingers to preview a list in the sidebar.
Easily move tasks between lists
Even easier-to-find Settings – just swipe from the left edge of the screen!
Clear for iPhone also now shows you the list name when you’re viewing a set of tasks.

This update was, by most counts, quite minor. Here is a look at Tweetbot before and after the update for iOS 7. (Image from Viticci’s extensive review over at Macstories).


Here are the release notes from the update:

Completely redesigned from the ground up for iOS7.
Native Push Notifications.
Mute filters lets you block messages from users without unfollowing them. Mute services, hashtags, people, and even keywords (regex included).
Sync timeline position, direct message read statuses and mute filters between iPhone, iPad, and the Mac via iCloud or Tweetmarker.
Customizable Navigation. The last 2 tabs are customizable and unused tabs are easily accessible.
Support for multiple services like Pocket, Instapaper, Readability, CloudApp, Droplr, and more.
Save drafts, add locations and POI’s, attach photos/videos, manage your lists, and much more.

Tweetbot wasn’t just fixed for iOS 7. It was rethought, redesigned, redone into a much nicer an experience and a much faster an app. Similar magnitude of delta was involved with 1Password and Screens updates. While Clear was made universal in the new update, it also meant that the users who paid $1.99 for the iPhone app (probably not too long ago) and do not own an iPad were expected to buy another app just to get fixes and enhancements. While in an ideal world, it’s not too outrageous to spend a couple of dollars to support apps which we use everyday, multiple times, in reality one can understand why reviews like these will be written:


A less controversial way for Realmac would have been to update the iPhone app for iOS 7 and launch a new one for the iPad. While realizing that there can be months of work put into making the app more functional, it might seem pretty shallow to say that unless there is a significant visual change, upgrade pricing will be backlashed at. However, the reality of the ecosystem is that iOS users have a very heavy visual bias, more so than others. This is a design-inspired platform and users’ expectations are set accordingly. Further, it is not so unfair on users’ part to expect functional and design overhaul when paying again for an app that still works.

While there will always be customers who would despise a developer for not supporting a ¢99 app perpetually and for wanting to pay her bills, I believe that most users are a bit more reasonable than that. However, when seemingly taken for a fool, there will be backlash. While I have heard some whining on Twitter about Tweetbot’s upgrade-pricing, the overwhelming response has been of great satisfaction and delight. So much so that Tweetbot 3 became the top paid app in 35 countries. Rightly so, Matthew Panzarino notes at the end of his Tweetbot 3 review over at Tech Crunch:

I want to pay Tapbots for their hard work getting this thing in the shape that it’s in, which is fantastic. And paying for all of those months of work is the least that most of us can do for as much utility as Twitter power players get out of the app.

Tweetbot 3 very well goes on to establish that paid-upgrades is a viable model of doing business in the AppStore. However, one has to be mindful that there must be significant marginal value for the users in the upgrade and their choice to not do so is respected and not dismissed with a cheap-shot.

Off Indeed

We cannot pretend to know much of what’s going on at Apple. With their very limited public exposure, Keynote events are the times when we try to grasp onto every little bit of inference that can be drawn and data that can be gathered. Sometimes, it might happen that we just end-up reading too much into things.

However, I believe I agree with Marco’s assessment of the Oct 22 Keynote event which saw the unveiling of the iPad Air and a Retina Mini alongside some really nice updates to the Mac lineup and the launch of the fabled Mac Pro.

The presenting executives seemed a bit off, too. Their energy was flat, as if Apple wasn’t particularly excited about these announcements either (with the notable exception of Craig Federighi, who was properly energized and most polished). Most of the jokes and digs at competitors were awkward. The lines were so tightly scripted that the presenters often stumbled off-script slightly, and rather than rolling with it naturally, they’d just jump back and awkwardly retry the line. Nothing about the speeches seemed natural — at best, the presentation felt uptight.

There were many times when they stumbled on lines and corrected things. This is out of ordinary for Apple events. While people have stuttered on the stage before, the frequency and the way it was handled this time just felt under-rehearsed and edgy. Schiller felt very forced to me and there wasn’t much excitement beyond Federighi’s OS X demo. iPad launch felt a lot like Schiller going through a feature checklist.

I cannot even speculate about the reasons. They might just not find all these incremental updates as interesting as what’s in the works. Or, they might just think that these presentations don’t carry that much weight anymore. Or they might be having an off-day[1].

  1. If that’s the reason, I will blame Carl Icahn. I am sincerely concerned about him and his effect on Apple. I believe Apple will hold its ground and not relent to his greedy and almost-malicious demands.  ↩