Posts in stories

The World of Indie App Developers

Here at MacStories we write about apps. A lot. Many of those we write about, perhaps even most, are created by individuals and small teams. And typically, those hard-working individuals remain unknown to the public who just know an app as something they use. Today we want to bring a bunch those indie developers to the forefront.

I wasn’t sure exactly where it would lead, but last month I asked on Twitter for independent developers to @ reply me and say hi. Amplified by retweets by Federico and many others, I got dozens and dozens of replies, ultimately totalling just under 200 responses.[1] That’s both a pretty huge number (trust me, it was a time consuming process documenting them all) and also incredibly tiny (there are around 250,000 active developers and over a million apps for sale).

It would be completely ridiculous to perform any kind of analysis on such a small sample size, but it was nonetheless great to have a relatively varied spread of developers from all over the world (illustrated in the above graphic). But more valuable was the list of developers and their Twitter accounts. So I’ve created a Twitter list that includes every developer that @ replied me. We’ve also included the full table of every developer we collated, links to their apps, location and Twitter account (see below). Please note that developers and apps shown in the full list does not mean they are endorsed by me, Federico or MacStories. If a developer met some very minimal criteria, they were included.

Read more


A History of Apple News and Rumors During CES

To those of us who follow technology news closely, this time of the year is dominated by the barrage of CES news. But it often seems as though Apple, which doesn’t attend the exhibition, also has some of its biggest days in the press – coincidentally, or not. This was brought to light again yesterday as Mark Gurman of 9to5Mac published details of a rumoured 12" MacBook Air and a timeline for the Apple Watch launch. I have no idea whether the information leaked to Gurman was timed to coincide with CES or not – it may very well just be completely unrelated.[1]

But regardless of the intention of Gurman’s leaker, I was curious to see whether Apple really did have big news days during CES in past years as I had remembered. So I ventured over to Techmeme (which links to big technology stories every day) and went into their archives to look at what was on their front page at 7:10 PM on every day of CES since 2007. Whenever a big Apple news story appeared, I made a note of it. This is the result.

Read more


Balance

When I started MacStories in 2009, two pillars sustained the narrative around Apple: its “attention to detail” and the “just works” aspect of its software. Since iOS 7, it feels like those pillars have begun eroding at a quicker pace.

Read more


“Can the App Store Be Full?”

David Smith, in an excellent episode of Developing Perspective about the hyper-competitive nature of the modern App Store:

It's hard to talk to those people sometimes, because I have the understanding that it's very unlikely that you're going to come up with something that is truly new, or something that will be adopted just on its own merits, on it being novel and it being interesting. If you do, it'll likely be copied very quickly. It's just the nature of the store. If you want to make it in the App Store, it's much more a question of patience, a question of savvy maybe, too. Of being really thoughtful about how you're doing things from a business perspective, on keeping your expenses and your costs really really low. That's one point that I know I've been able to make a living out of this, is that I keep my expenses very low on the development side.

The entire episode is worth listening to (or watching), as David makes some great points about facing the realities of the App Store, which is “full” of free apps and where the majority of customers don't fall in the power-user end of the iOS device owner spectrum.

I started MacStories in April 2009, less than a year after the App Store opened. Over the years, I've tried and written about thousands of apps, generally from indie developers who have an idea and want to make an app out of it. From my experience, it's pretty clear that the people who used to make apps in the early days of the App Store have been forced to adapt to a race to the bottom, increasingly harder ways to monetize productivity apps, and a general saturation of ideas. With so many developers making apps, it's almost inevitable that the same idea will happen in different parts of the world at different price points. By 2008-2010 definitions, the App Store can be seen as “full” and the market is tough and sometimes unfair (also because Apple has been slow in providing better tools for testing apps or measuring analytics).

But, it's important to stress the amount of opportunities that new developers starting out today have to make a meaningful impact on the App Store. New ways to monetize, new technologies, new types of customers that are more diversified than five or four years ago. Apps like Workflow, Overcast, Newsify, Elevate, Clips – these, I think, are good examples of the kinds of businesses that can be explored on the App Store today.

By certain metrics, the App Store is less fun because apps are harder to discover, free apps with inferior designs and feature sets tend to dominate, and many developers haven't been able to adapt to new trends, rules, or limitations. And I'm especially sad when I hear the stories of developers whose livelihoods have been complicated by rip-offs, questionable App Store rejections, or piracy. That, unfortunately, is the consequence of a vast and popular marketplace where anyone can make anything within a few guidelines. Everyone is fighting for customers and survival.

Realistically, though, the App Store isn't “full” if you can adapt to its nature in 2014. New ideas are still possible and new apps will be invented to solve new problems for new customers. The App Store is denser, noisier, and more unforgiving than before; developing successful apps – even only by the sheer amount of functionality in iOS – requires more patience and scrupulousness than four years ago. And creating novel apps that are also successful is incredibly challenging and time-consuming. There's no one-size-fits-all solution to this other than advising against relying on luck alone.

The App Store is full of opportunities, but it's a lot of hard work – more than ever.


Twitter Clients in 2014: An Exploration of Tweetbot, Twitterrific, and Twitter for iOS

Twitter clients used to be a UI design playground. The growing popularity of Twitter, an open API, and the rapid takeoff of the App Store contributed to the creation of a defining genre of mobile software in 2009 and 2010: the Twitter client for iPhone. In the golden days of third-party Twitter apps, a good new client would come out at least every month, with several developers pitching their own ideas for what was meant to be a mobile-first communication network.

iPhone apps and the Twitter API were a perfect match five years ago. Twitter made sense as a social network in your pocket; Apple’s iPhone OS and newly launched App Store made that a reality. As a user, there was little friction in trying multiple Twitter clients: because Twitter data was always “in the cloud”, changing clients was like choosing a different outfit each day. The core Twitter experience would always be the same; the design and preferences around it would differ from client to client.

That was a time of astonishing innovation in mobile app design. Twitterrific, the first native Twitter client for iPhone, effectively invented key aspects of modern Twitter interaction and terminology; Tweetie, perhaps the most popular Twitter client of its time, pioneered touch interaction paradigms such as pull to refresh. And then there were Weet, Osfoora, Birdfeed, Twittelator, Echofon, Tweetings, TweetList, and dozens of other apps that helped refine and redefine the idea of what Twitter on an iPhone could be.

Good Twitter clients weren’t easy to create, but the challenge they packed was intriguing and flexible. As a Twitter developer, you needed to design an app that would primarily display textual information (this was before Twitter photos), handle hyperlinks, manage interactions between users, account for different network conditions, possibly integrate with third-party sharing services years before iOS 8, and, most of all, be fast, responsive, and easy to use. The constraints of Twitter clients in 2009/2010 freed many from the struggle of coming up with an original app idea.

If you’re using an iOS app[1] today, there’s a good chance some of its features or design ideas first appeared in a Twitter client five years ago.

We know how the story moved forward. In April 2010, Twitter realized that they needed an official iOS presence on the App Store, so they bought Loren Brichter’s Tweetie, relaunched it as Twitter for iPhone, and Brichter released the (unsurprisingly genius) Twitter for iPad.[2] For a while, it looked like Tweetie would live on, but then Twitter started adding questionable features to it, and it became clear that the third-party Twitter client would be persona non grata on the App Store.

Over the years, there have been countless examples of Twitter prioritizing their own app and a closed ecosystem approach over third-party developers and improvements to the API. From the infamous quadrant and token limits to the display guidelines and constant reticence about bringing new features to the API, Twitter has been nebulous in providing an official stance on third-party clients after the Tweetie acquisition, but the subtext of their announcements has always been fairly clear to everyone in the third-party scene. Twitter wanted people to use their official app, not a third-party client.

Before the Twitter acquisition in 2010, I was using a bunch of third-party clients but I had eventually elected Tweetie as my preferred one. After Brichter’s app turned into Twitter for iPhone, I stuck to it for a while, but then I was allured by Tapbots’ promise of a Twitter client for power users. As I wrote in my original review, Tweetbot had everything I was looking for, and that was before Tapbots would bring fantastic new features that made it even more versatile.

I loved Tweetbot in a way that I didn’t love any other app for iOS. I have extremely vivid and personal memories of getting the first beta builds of Tweetbot for iPhone and iPad, and, until Editorial came around, Tweetbot was the app I spent most of my days in. From 2011 until earlier this year, I used Tweetbot every working hour of every day. Tweetbot was Twitter for me.

That’s not to say that I stopped checking in on the state of other Twitter clients for iOS, but I certainly became less curious because I had found the one. I’ve primarily continued to keep an eye on Twitterrific, but I largely ignored the third-party space for two years. Last year, the launch of iOS 7 motivated me to look for new Twitter clients again and I stumbled across new versions of TweetLogix, Echofon, and Tweet7, but my affection for Tweetbot and the fact that the majority of my Internet friends were using Tapbots’ app convinced me that I didn’t have to look for anything else.

I like to think that I’m naturally curious, but, for my Twitter client of choice, I had become complacent and fixated on the belief that the official Twitter app could never offer anything valuable again. Earlier this year, an idea started poking me in the back of my mind: if the rest of the world is using the Twitter app for iOS, shouldn’t I give it another chance?

This realization came from a simple occasion: I was having dinner out with some friends, and I noticed that they were using the Twitter app for iPhone to read news and follow their favorite celebrities. Tweetbot was Twitter for me and I was certain that I could never switch to another app, but they seemed to be just fine with the official app and its lack of streaming, mute filters, quick actions, and all those other great details Tweetbot had. “They’re not power users”, I thought, and that settled it.

Still. For someone who likes to think he’s curious and writes about apps for a living, my unwillingness to at least try the app from the service I use every day was remarkable in its shortsightedness. Twitter had changed since 2011, and it wasn’t meant for power users. The rest of the world was using Twitter through the official apps and I thought that I knew better than anyone else. So, a fun experiment began:

I started using the official Twitter client as my main Twitter app on my iPhone and iPad.

For the past six months, I’ve been reevaluating my entire Twitter experience based on the apps I use to read tweets and interact with people. The idea made a lot more sense once I stepped out of my preconceptions: I wanted to understand what 2014 Twitter was like and if that meant sacrificing my nerd cred and use a Muggle’s Twitter app, so be it. But at the same time, I’ve gone back and forth between Twitter and third-party clients, primarily out of habit, but also because they still offer powerful features and design details that I appreciate.

I didn’t want to focus on the history of Twitter clients, my thoughts on Twitter’s policies, or every single Twitter app currently available for iOS 8. I also couldn’t compare every single feature or design decision for every possible scenario a Twitter client could be used in.

Instead, I attempted to address my curiosity from a utilitarian standpoint. Given the three most popular Twitter apps for iOS (Twitter, Tweetbot, and Twitterrific), I wanted to slowly evaluate their features for my use case. To do this, I assembled a list of features I need a Twitter client to be capable of handling and I started taking notes every time I switched between clients. I’ve been doing this since early June.

I’ve spent weeks comparing features and changing apps to understand the kind of experience they want to promote. But implementation details and design differences aside, I also kept wondering the same question: was the real Twitter different from the third-party clients I used for three years?

What’s 2014 Twitter like on iOS?

Read more



Snapchat’s ‘Our Story’ Events Are a Captivating Experiment

I use a lot of apps, but there are only a few that I open every single day, and over the past few months Snapchat has become one of those elite few for me. If you told me this back in January, I wouldn’t have believed you and probably would have laughed at the idea too. Why the drastic change in opinion of Snapchat? Well, I eventually signed up when a few of my friends convinced me to, but my usage really skyrocketed with the launch of their (relatively) recent feature called ‘Our Story’. But first, an explanation of Snapchat and how it has rapidly evolved into a number of different features.

Read more



iOS 8, Email, and Extensions

One of my biggest frustrations with iOS 8 so far is the lack of extension support in Apple's Mail app. As I wrote in iOS 8 Changed How I Work on My iPhone and iPad:

I'm disappointed to see a lack of extension support in Apple's own apps, and particurlarly in Mail. It just makes sense, in my opinion, to be able to turn messages into tasks or archived documents, but Apple hasn't integrated extensions with Mail yet.

My feelings haven't changed since September and, in fact, Mail's non-existent sharing capabilities have been exacerbated by my move towards a more iPad-centric workflow after upgrading to an iPad Air 2. I've been working from my iPad Air 2 on a daily basis for the past two weeks, and the friction in Apple's Mail app has led me to use other email clients simply because they came up with their own implementation of action and share extensions for email messages.

Read more


iOS 8, Accessibility, and Third-Party Keyboards

In the overview I wrote for MacStories of the new Accessibility features of iOS 8, I said this about the operating system’s support for third-party keyboards:

This topic (as well as QuickType) is worthy of its own standalone article, but the accessibility ramifications of iOS 8’s third party keyboard API are potentially huge for those with special needs.

Four months later, that statement still holds true.

Over the past few weeks, I’ve been using two such keyboards — Fleksy and Keedogo — in an effort to not only simply test-drive a new feature, but also to gauge the accessibility merits of the keyboards. While I’ve found Fleksy and Keedogo to be fine in terms of accessibility, even in the midst of testing them, I’ve found myself going back to Apple’s stock keyboard. In the end, that I don’t use any third-party keyboard as a replacement for the default one on my iOS devices is no fault of either developer — it’s Apple’s.

Before explaining why it’s Apple’s fault, though, it’s important to discuss the virtues of Fleksy and Keedogo.

Read more