Posts tagged with "developers"

Discovery on the App Store

Gedeon Maheux writes about search on the App Store following a simple experiment: looking at search results for “Twitter”. The outcome is concerning:

The following list was generated by a manual App Store (iPhone) search on Nov 15th, 2014 for the term “Twitter”. To make the list easier to parse, I’ve called out all apps that allow a user to directly read AND post to Twitter in bold. Everything else is either a game, a utility, or some other social network enhancement. The official app from Twitter is naturally the first result, but the next actual Twitter client (Hootsuite) doesn’t appear on the list until #20 and the next one after that comes in at #62. Even the mega-popular Tweetbot isn’t returned in the results until position #81 and even then, the older v2 of Tweetbot (for iOS 6) comes first. Where’s Twitterrific? Although it contains the word “Twitter” in the app’s name, Twitterrific isn’t seen in the list until you scroll all the way down to #100.

App Store search has historically been a black box. The problem isn't necessarily that it's getting worse – rather, it's that it doesn't appear to be getting better. Every day I search for something on the App Store and, inevitably, I come across unrelated social games, apps to boost your Twitter followers or Instagram likes, and clones of other apps instead of more accurate results.

In spite of Apple's efforts to put curated lists of apps front and center, people still search for apps the old fashioned way. A mobile take on SEO has become quite popular, studies suggest this, and, anecdotally, the importance of search – inside and outside of the App Store – can be easily measured.

Apple has plenty of room for improvement in App Store search; in the meantime, the upcoming app analytics should hopefully help developers understand how customers are finding (or not finding) their apps through search.

Permalink

“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.


HockeyApp Acquired by Microsoft

With a blog post, mobile development testing and feedback service HockeyApp has announced they've been acquired by Microsoft.

From the HockeyApp blog:

Microsoft has been a HockeyApp customer with many apps since the early days back in 2011, so they were already familiar with the stability and quality of our service. Creating the best developer experience is key to both Microsoft and HockeyApp, this includes delivering industry leading tools for the major mobile platforms: iOS, Android and Windows. We saw the potential of the added abilities and resources of Microsoft to make our platform even better. It may sound cliché, but it really does feel like a match made in heaven.

We want to be very clear about the most important thing: we remain dedicated to our mission of making the best mobile app development feedback and testing distribution platform in the world. Your HockeyApp apps and accounts will continue to work and the team has not stopped working on advancing the platform. Throughout the next few months, we’ll reveal more about our plans with Microsoft.

In a separate blog post, Microsoft has also shared details of what to expect from the near future of HockeyApp:

In the coming months, we will introduce new iOS and Android SDKs for Application Insights based on the features of HockeyApp. Application Insights offers a 360-degree view of application usage, availability, and performance across both client and server/cloud application components. Integrating HockeyApp crash reports with Application Insights usage analytics will extend device support for Application Insights across all major mobile platforms and make application analytics an ambient part of the application development cycle with support for all tiers of a modern “mobile first, cloud first” solution.

It's not surprising to see HockeyApp becoming part of Microsoft following TestFlight and Crashlytics joining Apple and Twitter, respectively. Mobile development testing has become essential to the app economy, and big companies want to control that part of the stack.

As a user, I always preferred HockeyApp to the original TestFlight. HockeyApp was fast, its Timeline view was excellent (see all beta builds from newest to oldest), and it was always more reliable than the old TestFlight. The new TestFlight, though, is much easier and integrated than third-party beta testing services: developers can add up to 1000 external testers using Apple IDs rather than device UDIDs. That alone has been a massively welcome change: I only need to give my email address to developers, and then I can download an app without going crazy with certificates and UDIDs.

Most of the betas I try for MacStories have switched to the new TestFlight. It's just too convenient and integrated. I do think, however, that there's still room for services like HockeyApp, which offers developers more insights, cross-platform support, and the ability to avoid Apple's often problematic web services. It'll be interesting to see where Microsoft takes HockeyApp.

Permalink

Professional App Pricing

Rob Rhyne, in response to Allen Pike's post about the lack of a great app to record podcasts, has a few ideas about pricing professional software:

Professionals use your software to make money. If you can find a way for them to do their job faster or better, they will pay nearly any price. Did you purchase the maximum spec for your last computer or did you buy the cheapest you could find? Professionals always trade money for productivity. The real trick is building a product that makes them faster and better. Solve that problem and you can name your price.

I completely agree with Rob. Even on iOS, developers should consider creating professional software that's aimed at a specific audience willing to pay what is a considered a “premium” on the App Store. There are examples of developers that understand this well, such as Teleprompt+, Numerics, Omni's apps, and TrialPad.

If you can build a customer base that needs your app to get work done faster, there's a good chance they'd be willing to pay higher prices and reward you with commitment to the product, constant suggestions and bug reports, and no inclination to be curious about competing products, even if they're cheaper. I believe that's true on any platform and digital marketplace.

For more on this topic, check out Michael Jurewitz's blog posts from last year.

Permalink

The Effect of an App Store Feature

So, with almost 2500 downloads you are no. 128, and just 2k more gets you to no. 4. Wow. When you look at this, it’s not really that much top-heavy as I thought. It seems that with decent media exposure you can get pretty consistent number of downloads and chart ranking.

Aleksandar Vacić's new app, Run 5k, was featured by Apple, and he posted detailed numbers about the effect of Apple's feature. It's easy to guess that an Apple promotion on the front page of the App Store may help with downloads, but Aleksandar has actual numbers, and it's interesting to look at his graphs to observe the effect over time.

Permalink


iTunes Connect Shutting Down December 22 to December 29

In an email sent to iBooks publishers last night, Apple confirmed that iTunes Connect will shut down for a week from December 22 through December 29. While the email has been sent to registered iBooks Store publishers, Apple's annual iTunes Connect holiday shutdown will also affect iOS and OS X developers, who during that time won't be able to access iTunes Connect.

From the email:

From Monday, December 22, through Monday, December 29, 2014, iTunes Connect, iTunes Producer, and iTunes Connect for iOS will be unavailable.

During this time, you will not be able to access iTunes Connect, submit new books or book updates, or make price changes. You can schedule a book release or price changes to take place between December 22 and December 29. Just make sure that your changes are scheduled, submitted, and approved by December 18, to ensure your book remains available during this busy period.

For users, this means that no new apps, updates, or price changes will be available during the week. Developers who wish to release new apps and updates or price changes to apps or In-App Purchases will have to do so before the iTunes Connect shutdown.

Currently, Apple has only shared the 2014 iTunes Connect holiday shutdown dates with iBooks publishers; a developer update should be posted on the company's Developer News page soon.


Longtime Indies on the iOS App Store

Last week, I asked on Twitter for examples of individual developers who have been making and maintaining iOS apps for the past five years.

I was thinking about the App Store market for indie developers, and I was particularly interested in knowing for how long a single person can keep working on the same app. Is it because the same app makes for a good business even after several years? Is this commitment related to respecting an existing user base or scratching your own itch? Is it a combination of all of the above?

Note that I asked for individual developers and apps that are still maintained – not small teams of multiple people, and not apps that were released five years ago and never updated. I'm fully aware of the fact that no developer is an island and that, in the indie iOS development community, developers tend to help each other out and collaborate. And in no way I asked that to imply that teams of two or more developers “have it easier” or that it's “better” to be a single person who makes apps. I think it's pretty clear that I have the utmost respect for larger companies and smaller indie shops that create apps for the iOS App Store. I was simply curious: how many individual developers make an app and stick to it? Who are they?

I received a lot of responses, which were extremely interesting and contained a lot of great examples. So after coming up with a way to collect all those tweets, I created a workflow that uses the Twitter oEmbed API in Editorial to compile those links in a list of embedded tweets you can find below. If you're reading this through an RSS reader, you may want to switch to the website for the correct visualization.

This is obviously a small sample based on an informal poll of the people who follow me on Twitter, and it's not indicative of the financial viability of the App Store market for indies. I don't know how these apps are doing or if it's worth updating them from a financial perspective. But still, if you ever wanted to know what are some examples of individual developers who created apps 5/4 years ago and still maintain them today, you can find some tweets below.

Read more


Sketch to App Store

Created by Cluster Labs, this file for Sketch 3 sounds like a great idea for iOS developers (via Jeremy Olson):

This Sketch file is designed so you make a few changes to the setup page, and over 40 other artboards will be updated with your custom info. Within minutes, you'll be able to export 45 screenshot images.

I constantly hear that generating screenshots for multiple resolutions and languages for iTunes Connect is a time-consuming process. Sketch to App Store seems to automate several tasks involved with generating App Store screenshots such as device templates, text, resolutions, and, of course, exported files.

Permalink

Different Share Sheets

Alvaro Serrano makes a great point about share sheets and extensions in apps updated for iOS 8:

With Reeder’s iOS 8 update, this means Reeder users now have two different ways to send an article to Instapaper: they can use the app’s built-in Instapaper integration, or they can use the Instapaper Extension via the Share Sheet. This looks redundant, but there’s a catch.

In order to use the Instapaper Extension, the Instapaper app must be installed on the device. But what happens if you don’t want to have Instapaper on that particular device? What if, for instance, you browse through your RSS feeds on your iPhone but only read articles on your iPad? In order to do that using Extensions, you’d need to have Instapaper installed on both devices. Using Reeder’s built-in Instapaper integration, however, you’d only need to have it installed on the iPad, which is where you’re actually going to use it.

He uses the latest Reeder as an example, but the same is also true for Unread, Dispatch, and other apps that used to have custom sharing options before iOS 8.

For developers, there are several trade-offs involved with keeping old sharing options and implementing Apple's new action and share extensions. Do you want to handle user credentials for web services like Instapaper and Pocket, bundling a custom sharing menu that you have to manage? That would also give you more control over the entire sharing feature – for instance, users may be able to activate the service anywhere and not just from a share sheet. As an example, think of how Tweetbot could show read-later options before the iOS 8 update.

On the other hand, extensions free you, as a developer, from the burden of asking users to enter their credentials, designing a login flow, implementing error checking, or creating a UI for each supported option. You just need to support the system share sheet and pray that it'll work. And, obviously, iOS 8 extensions will give you all the benefits of a unified system: they're secure, they have an interface designed by their own developer, and they work consistently with other apps.

For now, I don't think pre-iOS 8 share sheets with hard-coded options will be going away. But as the extension system matures and developers start releasing new apps for iOS 8, I believe that the need for custom sharing options will naturally decrease, letting native extensions take over and benefiting users and developers.