Tag Archives: appstore

Micro.blog iOS 1.1

Micro.blog for iOS version 1.1 is now available. This release adds a number of new features:

  • Added support for longer posts with titles. Type more than 280 characters to reveal an optional title field.
  • Added Markdown syntax highlighting while typing.
  • Added formatting bar for common styles. Select a phrase and tap the link button for easier markup.
  • Added support for uploading multiple photos.
  • Added a Browser sharing item to open the current post on the web.
  • Fixed a potential crash in profile links and glitch when holding down to select text.

Here’s a quick screencast showing some of the highlighting and title support:

Hope you like the update. You can download it from the App Store

The iOS 11 App Store redesign story

Three years ago I wrote that Apple should end the App Store top 200 lists, learning from Beats Music how to double down on curation:

I wrote about Beats Music earlier, how it underscored to me that Apple needs to find the next product category to fall in love with, just like they used to feel about music. Of course we know that Apple already loves apps. Show that by doubling down on featured apps, staff picks, and app playlists.

And:

Apple shouldn’t wait until Thursday to feature a few great apps. Feature apps all the time. They’re on the right track with some of the “best of” sections in the store, and with the “Near Me” feature. Go a little further and it will make all the difference to bubble up great apps, and let the junk in the App Store fade away.

I think they’ve done it for iOS 11. While the top charts aren’t completely gone, they no longer dominate the App Store user experience. Featured apps are center stage.

Product manager Pedraum Pardehpoosh at WWDC even used the same phrase “double down” when describing Apple’s new focus on editorial content. During session 301, he said:

We thought this was a perfect time to double down on the editorial curation that’s distinguished the App Store since its conception.

Joe Cieplinski addresses the information density in the new App Store, pointing out that apps will be featured every day:

That’s a big change from the weekly update schedule Apple has maintained since the beginning of the App Store. You can’t name something “Today” and then not update it every day. So instead of a few new items getting featured once a week, something new will be featured every single day.

The “Today” tab is effectively a blog: reverse-chronological posts about what’s noteworthy in the store. It’s a much better default UI for content that is actively curated.

The old App Store was designed like a database. Databases are good at showing grids and lists from an algorithm. But the App Store should tell a story about new apps. A blog-like format is the best way to do that.

This plays to Apple’s strengths in design and taste. Where Google might hire more engineers to improve their store, Apple should hire more writers.

So far I’ve only used the new App Store on my iPad, and only for a few days. After we’ve all lived with it for a few months, it will be easier to judge whether it works for developers. But it’s almost exactly what I was hoping for a few years ago. This redesign for iOS 11 is one of my favorite things to come out of WWDC.

Core Intuition 254 and Kapeli wrap-up

On Friday, Daniel and I recorded and published episode 254 of Core Intuition:

Daniel and Manton dive into Apple’s controversial suspension of Dash developer Kapeli’s App Store account, and respond to listener Q&A about whether non-sandboxed apps are at risk of removal from the Mac App Store.

Covering sensitive subjects like Kapeli’a suspension is difficult in a podcast format where you can’t perfectly prepare your thoughts. Did I go too far defending Bogdan Popescu? Did I not go far enough?

Maybe we’ll know with some distance from this topic whether we reacted fairly. But I don’t think I overstated how important a moment this was for the App Store — both Apple’s influence over the narrative and as a test for their power in the store. Unfortunately the story still has a very unsatisfying ending.

Kapeli’s suspension is a test for Apple

Since my post yesterday about what I viewed as the unwarranted smearing of Kapeli’s reputation, I’ve received a lot of good feedback. I’ve also seen many comments from developers who had an incomplete view of the facts. This isn’t surprising, since Apple’s own statement to the press seems to have left out details, either for privacy reasons or to make a stronger case.

I’m not an investigative journalist. I know a lot about what happened, but not everything. I’m not going to try to “get to the bottom” of the truth. Kapeli developer Bogdan Popescu emailed me yesterday after my post had been published, and as tempting as it might have been to ask him more questions, ultimately this is between him and Apple. I’m a blogger and podcaster, so I’d rather stick to the larger themes.

How do we move forward as a community? Two points:

  1. We must err on the side of defending indie developers, even when it looks bad. Apple’s a big corporation and they don’t need our help.
  2. We should hold Apple accountable when they overreach, even when they have the best intentions. I agree with Rene Ritchie’s post that despite such a bad situation, it’s still within Apple’s power to fix this.

Matt Drance had a series of tweets that get to the heart of how we react as a community. If it turns out that Bogdan did submit fraudulent reviews, then okay. But if Apple eventually reinstates his developer account, I want to be able to say I stood up for his side of the story, even if I risked being wrong.

It’s easy to defend someone who is obviously innocent. It’s harder when they make mistakes, but in areas unrelated to the crime. In that way, this App Store “rejection” is unique. It may be the most important test we’ve seen of Apple’s power in the store.

Kapeli’s reputation

I’ve been using Dash more and more over the last month, but I realized with all this controversy that I had never actually bothered to pay for the app. Whoops! The trial reminds you every once in a while, but otherwise it’s pretty usable without paying, and I’m lazy.

Kapeli’s iOS revenue has vanished, but the developer still has his direct Mac sales. So I set out to finally buy a copy of the Mac version.

And then during checkout, sending him my name and contact info, I hesitated. Do I trust this developer? Is he trying to do the right thing for customers, as every indication from his public blog posts and tweets about Dash show, or is he a scammer, conducting fraudulent activity in the App Store as Apple accuses?

That’s the damage Apple has done in going to the press and smearing him. They’ve destroyed the goodwill he had in the community from his well-respected app. I always want to give people the benefit of the doubt, yet I hesitated.

At the Çingleton conference in 2013, Christina Warren talked about building a reputation for herself. One of the slides will stick with me for a long time: “All I have is my name,” she said, so she couldn’t risk attaching her name to something she didn’t believe in.

Kapeli developer Bogdan Popescu has made some mistakes. There’s a lot of smoke, but I still believe there’s no fire, no actual fraudulent activity orchestrated by Bogdan himself. That hasn’t stopped Apple from burning his reputation to the ground.

As long as Apple has so much control over app distribution, so much power over an iOS developer’s business and reputation, then Apple’s treatment of and communication with developers has to be perfect. Michael Tsai covers some of the ways Apple mishandled this. The fallout in the developer community has been more severe than is warranted from the incomplete and misleading facts in Apple’s statement.

I finished checking out and paid for Dash. It’s a great app.

Apple’s control over app hosting

High-profile app rejections aren’t as common as they once were, so it’s even more shocking when an entire developer account is banned from the App Store. Dash from Kapeli ran into this after trying to migrate an account:

Today I called them and they confirmed my account migration went through and that everything is okay as far as they can tell. A few hours ago I received a “Notice of Termination” email, saying that my account was terminated due to fraudulent conduct.

Brent Simmons writes about the lack of transparency and minimal appeal process:

While this is legal, and within Apple’s rights, it’s not what we’ve come to expect from a moral judicial system. No matter what the context, we expect that the accused see the evidence against them, we expect avenues for appeal to be made available, and we expect proportional penalties.

I hope this misunderstanding with Dash will be cleared up soon. But issues like this will never completely go away until Apple separates app distribution from curation. As long as there is a centralized, tightly-controlled system for installing iOS apps, mistakes will happen.

Imagine instead if the App Store worked more like the web. Google dominates search, but they can’t shut down your web site. If you try to game the system, Google can remove you from search and limit your exposure. Likewise, developers should be able to distribute iOS apps with minimal involvement from Apple, yet apps that haven’t passed formal review won’t be searchable without a direct link, won’t ever be featured, and won’t show up in the top 100 lists.

A more open system for app distribution would cleanly solve several problems with the App Store. Apple would be more free to remove clutter from search results without necessarily purging apps from the store. And there would be a natural temporary consequence for suspected fraudulent behavior: simply demote the app, delisting it from search and featured collections.

Apple should focus on highlighting the best apps within a system that lets the app review team make occasional mistakes. There shouldn’t be such an easy toggle that wipes out an indie developer’s business.

Long vs. pure App Store names

David Smith has an analysis of long names in the App Store, as developers try to understand the scope of Apple’s upcoming cleanup changes. Don’t miss the text file of 255-character names he found, which are all ridiculous. I’d laugh if this kind of gaming of the store didn’t make me sad.

I’ve always thought that the title shown in the App Store should be the actual app name. Keyword spamming is clearly bad, but I personally don’t like even tag lines in the name. Of the 4 apps from my company Riverfold that have been in the App Store, the names in the store all exactly match what is shown on your home screen:

  • Sunlit
  • Tweet Library
  • Clipstart
  • Watermark Mobile

Maybe my sales suffered because of my refusal to add more words after the real name, but to me, these names are pure and gimmick-free. I don’t want my customers subjected to a truncated mess of words even before they use my app.

If tag lines and brief descriptions in the App Store name are so common (and they are), then Apple should complement the new 50-character limit by having a separate 1-line description field in search results. This was discussed on the latest episode of Release Notes. My worry is that Apple attempts to fight problems with new policy alone instead of also encouraging the right behavior with App Store features.

App Store cleanup

I’m in favor of Apple’s upcoming app store cleanup, as long as they err on the side of keeping an app in the store if it isn’t clearly broken or abandoned. They should start slow with the obvious cases: crashing on launch, not updated for retina or even 4-inch screens. There’s a lot of low-hanging fruit that could be programmatically swept through.

David Smith wrote about this kind of App Store cleanup over 3 years ago, arguing that Apple could do a lot without getting into the subjective quality of an app:

Instead, I think Apple would be well served to adopt objective measures for quality or at least freshness to improve the overall quality of the Store. Adopting such a policy wouldn’t fundamentally change the situation for developers; every app they submit already has to be approved. All that this would do is apply some of those same required criteria to the app on an ongoing basis.

John Voorhees picked up on the urgency of Apple’s new policy for an article at MacStories:

We are well past the time when the number of apps served as meaningful bragging rights for Apple keynotes. The directness in tone and relatively short time frame given to developers to make changes to apps sends a clear message – Apple is serious about cleaning up the App Store.

It remains a challenge to preserve the part of our culture that is captured in old apps. I wish Apple could aggressively curate the App Store and allow old apps to be archived and available. But that’s far from an Apple priority. For now, it’s right to present the best possible user experience for App Store customers.

App maintenance and subscription rejections

Jason Snell closed his first take on App Store subscriptions with a question about iPhone app maintenance vs. web services maintenance:

Whether Apple would actually reject a subscription-based app that doesn’t offer any functionality outside of itself, I don’t know. It sure wouldn’t be the first time there was a baffling App Store rejection. But does Apple really want to take the position that ongoing maintenance of a web service has value, but ongoing maintenance and development of an app does not? I don’t think it does.

As I wrote about in my post yesterday, users can more easily see the hosting costs for a web service. They’ve been trained by a decade of paying for web subscriptions. Maintenance for the app itself has some differences.

Think about how costs scale if an app becomes popular. A web service becomes expensive to run, often thousands of dollars each month. You could say that a developer’s time for app maintenance is also thousands of dollars, but it’s essentially fixed. Outside of customer support costs, the incremental cost to a developer for an app doesn’t increase in the same way it does for scaling a backend service.

I hate that Apple has the power to reject our business model for a potential app. I’m now leaning more to the idea that Apple should approve nearly everything and let customers decide on the value. But there is a difference between maintenance of an app vs. a web service, and the services that are clearly appropriate for subscriptions will be the most successful apps using this new model.

Core Intuition 236 and app subscriptions

We published Core Intuition episode 236 today, discussing the recent App Store announcements and a listener question about offices. We wrap up with plans for WWDC.

There has been a lot of great blog posts and podcast episodes already on the App Store subscription change. I listened to Under the Radar 31 and the Release Notes special edition today and recommend both. The most confusion seems to be around what kind of apps are appropriate for subscriptions, where by “appropriate” I mean “what Apple will approve”.

John Gruber also follows up at Daring Fireball on this question:

Professional apps that require “a lot of maintenance of new features and versions” don’t fit either of those categories. Would Twitter clients like Tweetbot and Twitterrific qualify for subscription pricing? After talking to Schiller yesterday, I thought so. Now, I don’t know.

As I mention on Core Intuition, apps that have a backend service with obvious hosting and maintenance costs — a music streaming service, an invoicing web app, or a blogging platform, for example — are easier for users to understand as needing to be subscriptions. Twitter apps are an interesting example because some are pure clients to Twitter’s backend, but many increasingly have their own app-specific services like timeline syncing or push notifications.

For years Apple has allowed apps to use auto-renewing subscriptions. I had an iPhone app and companion web service that was approved by Apple for auto-renewing subscriptions, after I made the case for the service as a “cloud” archive. From section 11.15 of the App Store review guidelines:

Apps may only use auto-renewing subscriptions for periodicals (newspapers, magazines), business Apps (enterprise, productivity, professional creative, cloud storage), and media Apps (video, audio, voice), or the App will be rejected

From my experience and listening to other developers, I’ve had the impression for a while that Apple would essentially reject most auto-renewing app submissions by default. While we still don’t know what “all categories” means in the new announcement, I expect it means that there will no longer be a kind of blanket rejection. Apple will still reject many apps as poorly suited for subscriptions, though, and maybe that’s okay for now.

(I’m conflicted on this point. John Gruber’s suggestion to approve everything and let the market decide is compelling and fits better with my instinct that the control should be in developers’ hands.)

“Subscription fatigue” is a real thing that I’ll occasionally hear from customers about. No one wants to pay $1/month to 40 different apps and services; it feels like a burden in a way that paying the same total price to just two apps at $20/month does not. Nevertheless, subscriptions are very powerful. Everything I’ve done over the last few years is to position myself to eventually have a recurring-revenue success.

Medium subscriptions

Glenn Fleishman writes for Six Colors about Medium’s subscription features that will let publishers charge readers:

It’s absolutely clear the revenue side is an experiment, and Medium labels it as such all over. There’s no guarantee it will work for its early partners or pan out in the long run. But it’s the only publishing option that combines so many things in one place without any over-the-top cost or commitment on the part of a periodical.

While Medium is certainly doing a lot right, and I still think it’s not a bad place to mirror content, the “long run” Glenn mentions is really what we should think about when considering Medium. I have no confidence that Medium will last 5-10 years.

If my whole business was based on blogging, why would I trust Medium to control something so crucial? With iOS development, we have no choice but to use the App Store. Writing on the web isn’t like that, and voluntarily giving up both control of the publishing platform and 20% of revenue strikes me as very short-sighted.

Paid search and App Store profit

Reacting to a Bloomberg article about Apple adding paid search results in the App Store, John Gruber writes:

This sounds like a terrible idea. The one and only thing Apple should do with App Store search is make it more accurate. They don’t need to squeeze any more money from it. More accurate, reliable App Store search would help users and help good developers.

The Bloomberg article almost makes it sound like there’s a 100-person team working on paid search. I doubt that’s true. More likely, there’s a team working on several improvements to the App Store, including better search.

Daniel Jalkut is also very skeptical:

It’s hard to see how paid placement would consistently benefit either Apple or its direct customers. It’s unlikely that paid listings would be used to highlight apps that are in line with Apple’s other goals for the store.

He rightly points out that making money from the App Store is Apple’s secondary goal. It’s more important to have an ecosystem of apps that make the iPhone itself indispensable. As I argued in a blog post in 2011 about free apps and distribution, I don’t think the App Store should be a source of significant profit for Apple at all.

And if we’re keeping score with old posts where I write not what Apple should do but what I wish they’d do, see “I hope iAd fails” from 2010. iAd is shutting down in June.

I just can’t believe Apple would prioritize paid search over all the other App Store feature requests that developers have. So I prefer to ignore the paid search rumor and instead take away from this article just the good news: Apple has a new team focused on improving the App Store.

Cute release notes

Ben Brooks takes on the trend of cute stories inside of release notes:

“With disturbingly increasing frequency, companies are deciding to let their marketing departments handle their release notes instead of the engineering team or product manager.”

I agree. These were fun at first, but the release notes don’t need to be entertainment. They should be a summary of what changed, with bullet points for key changes. (A single “bug fixes” line is also not helpful.)

I personally like to start each line with a clear statement: “Fixed <something>” or “Added <this feature>” or “Improved <something else> by <doing this>”. You can see this in the history of my Tweet Library release notes, for example.

iAd setback

I was confused at first by Apple’s iAd announcement to developers. I read it as iAd completely shutting down, but apparently it’s just the “app network”. Still, it’s a welcome setback for those of us who were never fans of iAd.

John Gruber doesn’t think Apple’s heart is really in it:

“When iAd launched, its biggest advocate among Apple’s leadership was Scott Forstall. In some ways I’m surprised it took this long for them to pull the plug. After Forstall, I don’t think anyone’s heart was in this.”

I agree. Back in 2010, I said that I hope iAd fails. It seemed at odds with Apple’s focus as a product company, not to mention hypocritical for a company with ad-blocking APIs. Apple and third-party developers should be united in encouraging users to pay for apps; iAd is a distraction from that.

Phil Schiller and the App Store

Apple announced some leadership changes today, including that Phil Schiller will now lead the App Store on Apple’s various platforms:

“With added responsibility for the App Store, Phil Schiller will focus on strategies to extend the ecosystem Apple customers have come to love when using their iPhone, iPad, Mac, Apple Watch and Apple TV. Phil now leads nearly all developer-related functions at Apple, in addition to his other marketing responsibilities including Worldwide Product Marketing, international marketing, education and business marketing.”

You may remember that Phil Schiller has gotten involved in controversial App Store rejections in the past, going back to 2009. See this post from Daring Fireball about Ninjawords, and another article at Techcrunch by MG Siegler.

On recent episodes of Core Intuition, and in a blog post, I’ve argued that Apple can’t just make small improvements to the Mac App Store anymore. The time for slow iteration is over; now they have to make big changes to get developers back. I’d like to believe that putting Phil in charge is exactly that kind of first big step.

Update: Less optimistically, though, there was this post in 2012 from Rogue Amoeba.

Gravity and the App Store

Dan Moren, writing at Six Colors about the rejected app Gravity:

“Really, what Apple needs is a small group within the App Store review team to flag apps that are pushing the envelope in smart, respectful ways; work with those apps’ developers; and present overall recommendations to App Store leadership—perhaps even reporting directly to Eddy Cue.”

I love this idea. It would both minimize unfair app rejections and help innovative apps bubble up to the featured sections in the App Store.

Peace, indies, and the App Store

You’ve probably heard that Marco Arment has pulled his content-blocking app Peace from the App Store. The app was extremely successful:

“As I write this, Peace has been the number one paid app in the U.S. App Store for about 36 hours. It’s a massive achievement that should be the highlight of my professional career. If Overcast even broke the top 100, I’d be over the moon.”

I’ve seen some comments asking why he didn’t think to do this sooner, before he even shipped the app. But we are just now starting to understand the impact of ad blockers in iOS 9. I don’t think it’s an exaggeration to say that the web is different than it was a few days ago, and so our choices — and Marco’s — are different too. As I mentioned yesterday, content blockers are one facet of an overall shake-up for the web.

Brent Simmons writes that only indies can do what Marco did. Marco must have left a lot of money on the table with this decision. It will always look like the right call to me when someone goes with their gut feeling and not with profit.

App Store delivery truck

Charles Perry follows up from Brent’s post on the App Store with this point of view:

“Today, the App Store is basically your delivery truck that takes cash on delivery. We wouldn’t blame a delivery truck for our business failure. It doesn’t make any sense. It’s not a delivery truck’s responsibility to ensure that there’s a market for our products. That’s what market research is for. It’s not a delivery truck’s responsibility to advertise our products or introduce them to customers. That’s what marketing is for.”

I really like this analogy. However, if you take everything Charles says as truth, it reveals an even more serious problem: the 30% that Apple charges for distributing bits on their truck is outrageous. It’s flat-out wrong to charge such a high percentage if they are providing no value above credit card processing and file hosting.

Tweet Library 2.5 and consolidation

There’s a new update to Tweet Library out today. Major additions include CSV file export to Dropbox and new URL schemes for starting a search, export, or publish. The URL schemes look like this:

twtlib://username/search?q=hello&collection=Favorites

twtlib://username/export?collection=Testing

twtlib://username/publish?collection=Testing

twtlib://username/storify?collection=Testing

There are a few other important bug fixes too, especially to importing the Tweets.zip archive from Twitter.

When I gave up on Twitter as a user, many people asked if I would abandon Tweet Library. I wasn’t sure at first, but the answer now is a clear “no”. In fact, since my last personal tweet in 2012, I’ve released new features and even redesigned the app for iOS 7.

But I do need to start consolidating my work on Tweet Library and Watermark, because the apps share so many concepts around archiving and search. To that end, this week I’m retiring tweetlibrary.com as a way to browse and publish collections. The site will now redirect to a special landing page on Watermark. Published collections from Tweet Library also go to a public page on Watermark.

It was a tough decision to change the tweetlibrary.com URLs, but maintaining separate web apps that are so similar made everything more complicated, holding back what I could build. Having a single web codebase (Watermark) will ultimately let me improve both Tweet Library and Watermark more quickly.

Like scripts in animation

This line in a blog post on Cartoon Brew made me laugh:

“It’s certainly possible to write a Looney Tunes script, just as it’s possible to eat a hamburger with your feet, but there are smarter, easier, and better ways to do it.”

Every industry that gets big probably has some of this. There’s the old school, the folks who know the right way to do things — for example, you start an animated film with sketches and storyboards, not words — and then there’s everyone who comes in afterwards, without the history and culture of what made it all work. Look at what the App Store has become, compared to how software development worked in the 1990s or early 2000s. If it wasn’t for all the money some of these new developers are making they’d be completely embarrassing themselves with technical naivety and depressing lack of vision.

On the other hand, great ideas often start with newcomers. But please respect the past before you break from it.