Tag Archive for ‘Developers’

Twitter Announces New API That Opens More Features to Third-Party Apps ➝

Filipe Espósito, writing for 9 to 5 Mac:

Twitter is announcing its new Twitter API v2, which was completely rebuilt with new features. One of the highlights of the new Twitter API is the real-time tweets stream — one of the options removed in the past. Third-party apps can once again load new tweets as they’re published and not just after a period of time.

Other changes to the API include conversation threading, polls, pinned tweets, better spam filter, and advanced search. The Twitter v2 API will be available on three different levels: Standard, Academic Research, and Business.

I hope this will bring about a resurgence in third-party Twitter apps. I think many of the problems on Twitter and the dread that one feels when reading their timeline could be mitigated, if not solved, with just a bit more creative thinking. The type of creative thinking that isn’t limited by the goals and priorities of Twitter itself.

➝ Source: 9to5mac.com

Twitter Needs Third-Party Clients ➝

Craig Hockenberry, referencing Ryan Christoffel’s recent piece on Twitterrific’s introduction of multi-window support and Twitter adding keyboard navigation to their app:

This review that covers a both a third-party and first-party Twitter app shows how important the former is.

Third parties are always first with platform features like multi-window on iPad. And we’ve had keyboard support for several years.

Third-party clients are the reason we have retweets, replies, mentions, blocking/muting, and more. Almost all of Twitter’s best features were first introduced and supported by developers outside of Twitter. The service would really benefit from a reintroduction of the APIs that allowed those apps to stand on equal footing with Twitter’s own client.

As a bit of an aside, I’m going to be giving Twitterrific another shot.

(Via Michael Tsai.)

➝ Source: macstories.net

In-App Opt Out

John Gruber, on Spotify’s recent “Time to Play Fair” campaign against Apple:

What Apple should do is allow apps that opt out of IAP to explain that users need to subscribe or make purchases using a web browser, and allow them to link to their website from within the app (even if they’d be required to open that link in Safari, as opposed to an in-app web view).

Everything else in Spotify’s list of complaints seems like noise to me, and distracts from the central issues — which happen to be the issues where Spotify should be on the strongest legal footing.

I agree that most of Spotify’s complaints feel petty and childish — many of their complaints are about limitations with third-party APIs for newly released devices. But I disagree that Apple should allow developers to opt out of the in-app purchase system.

While I do think Apple should reconsider the 30% cut and reduce it to something a bit more reasonable, I think it would be bad for customers overall if developers could point users to external places for digital purchases. One of the great benefits of the in-app purchase system is that it’s secure and trustworthy.

Over the past few years, I’ve had to have my debit card replaced three or four times, likely because of some security vulnerability in a payment system. I don’t have to worry about that with Apple, though. I trust that they’re doing everything they can to keep my payment information safe and secure. It’s hard to say that about others.

Perhaps I’m a bit too paranoid about the security of my payment information, but if a service allows me to pay through an in-app purchase, that’s what I use. This is how I pay for Hulu, the WWE Network, and even YouTube Premium — despite the fact that YouTube’s pricing is higher through the in-app purchase than it is if purchased elsewhere.

Here’s the thing about allowing developers to opt out: it’s a slippery slope. If Apple allowed developers to push users to a website for purchasing digital goods, they would. There are plenty of payment systems out there and building a website that integrates with them is easier than ever. But I don’t want to give my credit card credentials to every single developer that builds an app I’m interested in. Doing so will only increase the chances of my debit or credit card becoming compromised and then I have to go through the hassle of getting it replaced, which is a major pain.

To be fair, if developers used Apple Pay on their websites, these security concerns would be mitigated. But it’s not just the security aspect that has me on board with in-app purchases, simplicity is another major factor. The ability to quickly purchase a subscription through the app using my fingerprint, restore a subscriptions on another device, and manage all of my subscriptions in one a single location are niceties that would go out the window if Apple allowed developers to opt out.

That last point is a pretty crucial one for me. If I want to cut a subscription or two in a world where developers could opt out, I’d have to login to each service’s website and hunt around for the option to cancel my subscription. This seems like an awful experience compared to tapping on my profile picture in the App Store and selecting “Manage Subscriptions”.

Maybe I’m in the minority because I don’t use Netflix — I’m sure many iOS users already have plenty of subscriptions that they manage outside of the in-app purchase system and they get by just fine. But we need to consider whether allowing developers to opt out of in-app purchases is in any way an improvement for users. I don’t think it is. Don’t get me wrong, I truly want developers to have a sustainable career so they can continue building great apps. But isn’t providing the best experience for your users the best way to do that?

In-app purchases are always going to be superior to the alternatives and there are plenty of ways to fix the problems surrounding it without having to throw it out entirely by allowing developers to opt out.

What’s Next for Coda? ➝

From the folks at Panic, on the future of Coda:

We had to make a difficult choice: rewrite Coda for this new world, or leave it behind?

We’ve been making apps for a long time. And we never stopped having a passion for creating beautiful, functional, useful tools that help people do their very best work.

It’s what we are. It’s why we’re here.

So, you can probably guess what we chose.

I’m pretty excited about what they have in store for Coda and I hope they’ll be bringing many of the app’s new features to iOS as well. I built the entirety of Initial Charge’s current design in Coda for iOS and I’d like to do so again whenever I get the itch to refresh the design in the future.

Developers Can Now Request Access to Shortcuts TestFlight Beta ➝

Developers can head over to the Downloads page on Apple’s developer site and request to join the TestFlight beta — it’s the last item under the “Featured Downloads” heading.

Apple Makes Changes Inside and Outside the Mac App Store ➝

Jason Snell, writing on Six Colors:

The severe restrictions of the Mac App Store’s security policies were one of the reasons most frequently cited by developers who decided to bail out on the store and just go back to selling apps directly. It’s no coincidence that two notable developers who abandoned the Mac App Store, Bare Bones and Panic, were highlighted in a slide at the WWDC Keynote: That’s Apple sending a message to developers that the Mac App Store is changing and that they might want to give it a second look. I’d expect Apple to continue in this direction with the Mac App Store in the future.

The Mac App Store is a great opportunity for Apple to provide a safe storefront for customers and a means of discovery for the best Mac apps. But Apple must create an environment where developers can build apps that have the features that their customers want. Up until now, Apple wasn’t doing a good enough job in that respect. But I’m glad that they made the necessary changes to get the likes of Panic and Bare Bones Software back on board.

Apple Design Award Winners Announced ➝

Congratulations to this year’s winners, including my calculator app of choice and one of the best iOS games of all time.

Screwing Your Vocal Minority ➝

M.G. Siegler, with a great take on the Twitter API situation. I especially liked this bit:

What I think Twitter (and again, others) miss is that it’s not so much about the explicit influence, it’s far more implicit. And some of it is painfully obvious. It’s the fact that such users are often the most devoted, caring, and passionate ones. And sometimes, they’re at the forefront of what the rest of the user base will eventually feel because they’re so into the product. Other times they offer a power user perspective, which can be useful at times in showing how the product works (and doesn’t) in the ultimate “success state” of extreme usage. There are many other simple, subtle things that could be mentioned here.

It’s foolish to abandon users that contribute so much to the service.