A handy webapp by Mattt Thompson that, at launch, contains transcripts for WWDC 2013. As Matt explains, ASCIIwwdc has been created “by normalizing and indexing video transcript (.srt) files provided for WWDC videos”.
Check it out here.
Posts tagged with "developers"
ASCIIwwdc: Searchable Transcripts of WWDC Sessions→
Feedly Opens Up API→
From the Feedly blog:
Millions of users depend on their feedly for inspiration, information, and to feed their mind. But one size does not fit all. Individuals have different workflows, different habits, and different devices. In our efforts to evolve feedly from a product to a platform, we have therefore decided to open up the feedly API. Effective immediately, developers are welcome to deliver new applications, experiences, and innovations via the feedly cloud. We feel strongly that this will help to accelerate innovation and better serve our users.
API documentation here. I’m looking forward to playing with this in the next couple of weeks.
Taking Developers Along For The Ride→
Matthew Panzarino talked to several developers of third-party iOS apps about the importance of iOS 7 and what it means for the developer community. The background on the deeply-reimagined Evernote app (by CEO Phil Libin himself) is fascinating.
On OmniKeyMaster’s Shutdown
Two weeks ago, The Omni Group announced an app called OmniKeyMaster aimed at letting customers migrate from Mac App Store licenses to standalone ones that supported upgrade pricing:
OmniKeyMaster is a simple app that finds App Store copies of Omni apps installed on your Mac, then generates equivalent licenses from our store – for free. This gives Mac App Store customers access to discounted pricing when upgrading from the Standard edition to Professional, or when upgrading from one major version to the next. Another benefit: since they don’t have to wait in an approval queue, our direct releases sometimes get earlier access to new features and bug fixes. OmniKeyMaster lets App Store customers access those builds, as well.
Today, The Omni Group had to remove the app, presumably after pressure from Apple:
My apologies: I’m afraid we will not be able to offer upgrade pricing to our Mac App Store customers after all. So long as we continue to sell our apps through the Mac App Store, we are not allowed to distribute updates through other channels to apps which were purchased from the App Store.
This is strange, because a number of similar tools (made by other independent developers) already exist on the Internet and they have been letting customers generate standalone licenses for several months. Perhaps Apple just didn’t like that a name such as The Omni Group had found a way to make the process so easy? Was The Omni Group’s tool built in such a way that it broke some Apple rules? Did The Omni Group think OmniKeyMaster would be okay because other solutions existed? Is Apple going after similar solutions as well?
Stephen Hackett argues that The Omni Group should have foreseen this, but that the Mac App Store is, overall, good for most third-party developers:
While The Omni Group is probably big enough to walk away from the Mac App Store, a lot of developers are enjoying a level of success in the Store that they couldn’t enjoy without it. Apple shouldn’t use that to strong-arm developers from trying to workaround the system. That puts both Apple and third-party developers in a pretty crappy spot.
I see both points. The Mac App Store is good for some developers and end customers, but it could be improved in so many ways. Is it a surprise that, after an initial rush to sell apps on the Mac App Store, more and more developers of apps above the $2.99 threshold (read: not games and utilities) have gone back to selling both App Store and “regular” versions?
The Omni Group wanted to do the right thing and offer upgrade pricing for customers who bought an app on the App Store. Apple doesn’t like the idea and leads by example with a new version of Logic Pro sold as a new app, without upgrade pricing. If my assumption is right and Apple is behind OmniKeyMaster’s premature demise – how could they not be? – that’s really sad.
Apple shouldn’t put pressure on developers who tried the Mac App Store model and didn’t like some parts of it. Instead of burying their head in the sand and pretending that developers who want upgrade pricing don’t exist, they should work with those developers to resolve their issues. The App Store launched in January 2011 and these aren’t new problems. If Apple doesn’t really care about upgrade pricing, it seems curious – to me, utterly wrong – that they’re going after a clever tool like OmniKeyMaster.
And if you think that it’s in Apple’s right to shut down OmniKeyMaster1, then I guess it won’t be a surprise if more developers will keep offering standalone versions of their apps in the future, possibly even eschewing the Mac App Store if necessary.
Most people don’t have time to care about these issues, because they like the convenience of the Mac App Store. But I do, and therefore, whenever possible, I try to buy Mac apps from a developer’s website. It’s worth the extra effort.
-
In the way that OmniKeyMaster worked – as a separate app that wasn’t built into Omni’s App Store apps – I don’t think The Omni Group was violating Apple’s 7.1, 7.2, and 7.15 Mac App Store guidelines in any way. But, based on this tweet by Ken Case, it sounds like Apple has changed its mind. ↩︎
The Omni Group Releases OmniKeyMaster Mac App Store License Tool→
From The Omni Group’s blog:
OmniKeyMaster is a simple app that finds App Store copies of Omni apps installed on your Mac, then generates equivalent licenses from our store - for free. This gives Mac App Store customers access to discounted pricing when upgrading from the Standard edition to Professional, or when upgrading from one major version to the next. Another benefit: since they don’t have to wait in an approval queue, our direct releases sometimes get earlier access to new features and bug fixes. OmniKeyMaster lets App Store customers access those builds, as well.
Tools like OmniKeyMaster have become quite common lately, as developers of third-party Mac apps keep struggling with the limitations imposed by Apple on the Mac App Store. Having new versions of apps every time a major upgrade is released isn’t an option for many developers, and they are resorting to workarounds like this to have the best of both worlds: the Mac App Store’s purchase system and the control on your own website and app updates. It’s a trade-off, and, in most cases, the process is quite convoluted.
In The Omni Group’s defense, their Mac App Store license tool seems easy to use and clever in how it finds all App Store copies of Omni apps on a Mac. Apple may not be interested in offering upgrade pricing on the Mac App Store, but developers find a way…or at least a viable workaround.
Stuart Hall’s App Store Experiment→
This is an excellent series by Stuart Hall: he developed a 7 minute workout app, and he’s been posting details, numbers, and comments on what it’s like to enter the App Store market today.
Particularly interesting is the switch to a free model with In-App Purchase, detailed in part two:
How does In App Purchase (IAP) stack up against a paid download? For this app it’s been an increase of over 3x from around $22 per day to around $65 per day. The IAP converts at approximate 2-3% of the downloads per day.
[…]
IAP increases revenues - For better or worse for the ecosystem as a whole, it’s been proven over and over again it makes more money.
While Stuart’s story won’t apply to every kind of app category and pricing scheme, there are several data points and charts worth considering. Make sure to check out part one and part two – I hope there will be a part three as well.
iOS 7 Apps and Aggressive Adoption→
David Smith, on deciding to go iOS 7-only for his next app updates:
Today, I’ve reverted my position again. I am going to be aggressively adopting iOS 7 exclusively in my apps.
This change is mostly a result not so much of the technical or business implications of supporting legacy versions but of quality assurance needs. I have been able to manage working out the technical needs of supporting both versions but I have found that the time and energy required to test and validate the applications on both is becoming too much of a burden.
Aside from a technological standpoint, I think the most important factor to consider is that users can’t wait to get their hands on iOS 7. The new version is a major change, and – at least based on my survey of non-geeky friends – I suspect that more people will upgrade more quickly than last year (the launch of iOS 6 surely wasn’t helped by doubts surrounding Maps).
With users being so excited for iOS 7, the decision of going iOS 7-only makes sense. At least, it’s a common pattern that I’m observing this summer.
App Updates For iOS 7→
Craig Hockenberry:
An overwhelming number of developers were updating apps for iOS 7. Of 575 valid responses, 545 developers indicated that they were working on an update for iOS 7. That’s an adoption rate of 95%!
From what I’ve seen (and heard) so far, it looks like releasing new, paid, separate versions of apps for iOS 7 will be a common trend among developers. I think that, in most cases, it makes sense considering the major rewrite and redesign required by iOS 7 to ensure an app can be technically and visually ready by this Fall.
If we’ll end up with an App Store full of old iOS 6 apps kept for “compatibility mode” or existing customers, I believe properly showcasing iOS 7 apps will be even more necessary in the (already crowded and poorly searchable) App Store.
Why Are Apps Putting You On A Wait List?→
A good piece by Ellis Hamburger at The Verge, who explains why some recent iOS apps have been putting new users on a “wait list” before they can actually start using an app. This is due to the increasingly cloud-based complex scaling challenges that apps (which are downloaded locally) face when trying to work with online components (remotely) for thousands of users.
I understand the difficulties mentioned by Ellis and the developers he interviewed, but I also see part of Ben’s point when he argues that several of these “wait list apps” are free and don’t seek immediate revenue. Mailbox removed the reservation system after it had been acquired by Dropbox, meaning that Dropbox – a larger company – had the human and financial resources to “throw” at Mailbox’s problem. However, I think that resources aren’t a panacea for new apps that rely heavily on server-side features: if anything, the App Store makes it hard to ship apps that are only available to a subset of users, which is forcing developers to implement ideas such as the aforementioned waiting lists.
A better testing process for App Store developers isn’t a new topic, and I wonder if app testing tools made by Apple with support for thousands (instead of hundreds) of “beta” users would alleviate the issues covered by Ellis.