Here comes desktop Retina.
Here comes desktop Retina.
This week, we discuss software methodologies. (Finally.)
Sponsored by In Flux, Squarespace, and Ting.
There’s not much actual information about CarPlay yet, but it’ll be a long time before it’s in enough cars on the road to be relevant.
It also has the potential to fizzle out because Apple demands more control than their partners are comfortable with, like iAd, or their interests conflict too much with the partners’ interests without enough upside to the partners, like iTunes TV rentals.
CarPlay will become much more interesting if and when, say, the millionth CarPlay-equipped car is sold to a customer, which is probably at least two years away even if manufacturer adoption goes very well.
Naturally, as a developer of a podcast app, I’ll support it if I reasonably can. It’s probably easy.1 But I don’t expect CarPlay support to be a significant force in the market for a while, if ever.
I’ve heard that there will be a CarPlay simulator for iOS SDK. I hope that’s true, since it would help tremendously — at least, if I’m allowed to develop for it. Apple’s language about third-party apps suggests (but doesn’t confirm) that it won’t be open to all developers, being limited to partner deals like Apple TV channels and Siri features. ↩
Lukas Mathis, a long-time Mac and iOS user, was frustrated by the iPad’s productivity limitations and has been using a Surface Pro 2 instead.
This is a fantastic article for so many reasons. If you care about any of this stuff — tablets, consumption vs. production, iOS multitasking, Windows 8 — set aside some time and read this.
The more I learn about pCell, the more interesting it sounds. It still blows my mind that such a concept can work at scale at all.
This week: Wolfram Language, Apple’s SSL bug and the NSA, warnings as exceptions in production, and that Scriptnotes episode.
Sponsored by Picturelife, Squarespace, and HelpSpot.
Great piece from Ben Thompson, although I don’t agree with his conclusions.
The argument that we don’t want “such a dysfunctional government” regulating broadband is weak: “the government” isn’t one big coordinated bogeyman that can’t be trusted with anything. That’s just rhetoric that politicians1 use to avoid regulation so corporations can make more money at the expense of the citizens or environment. In practice, governmental regulation works so well in most cases that it’s taken for granted and too boring for most people to even think about.
I also don’t buy the position put forward by the big broadband companies that regulation would hurt their ability to “innovate”. Innovation is almost certainly not what we want from our ISPs: introducing artificial limitations on cheaper plans, pushing normal service to higher prices, transitioning from monthly to annual contracts with zero consumer benefit, and bundling services you don’t want with your internet service are all considered “innovation” to an ISP. “Innovation” makes them more money or adds proprietary services so they aren’t dumb pipes.
We definitely don’t want any of that. We want our ISPs to be as boring as possible. Dumb pipes are exactly what ISPs should offer, and that’s what common-carrier regulation would maintain.
What we do need is continued coverage expansion and speed increases, but this has nothing to do with common-carrier classification. At all. It’s just political drama so they can avoid regulation and make more money. The big ISPs have always trotted out weak sob stories about needing zero regulation so they can keep expanding service, but these are really threats to the American people and government. “Give us everything we want, or we’ll hold broadband hostage.” They’ve always done whatever they wanted whenever it was convenient and profitable. And it’s very profitable.
What’s most damning to their argument is that they’ve all acted within common-carrier boundaries anyway for most of broadband’s existence, with very few exceptions, and they continue to make record profits, expand service (mostly), and increase speeds. Common-carrier regulation would simply prevent some very harmful “innovations” that the ISPs have, to date, never needed to remain profitable and keep expanding.
Don’t believe their bullshit. They’d be perfectly fine as common carriers. Almost nothing would change from the way they’ve always operated.
Usually Republicans, but Democrats certainly do their share of shamelessly serving big corporations at our expense, too. ↩
Reuters: (via DF)
Google Inc has deployed lobbyists to persuade elected officials in Illinois, Delaware and Missouri that it is not necessary to restrict use of Google Glass behind the wheel, according to state lobbying disclosure records and interviews conducted by Reuters.
I don’t think there are a lot of reasonable people still arguing today that texting while driving is safe.
No reasonable person who has used Google Glass could conclude that interacting with Glass while driving is substantially different from texting while driving.
There’s no gentler way to put this: When — not if — distracted drivers using Glass kill others or themselves in accidents, those deaths are now partly on Google.
Had Google just produced Glass, and harm resulted from misuse outside of their control, it wouldn’t be reasonable to ascribe much blame to them. But to actively fight against clear, valid safety concerns makes them an accomplice — morally, if not legally.
This action by Google is simply reckless, disgusting, and disgraceful.
I’ve seen this podcast-episode link recommended a few times by fellow software developers over the last couple of weeks. I finally listened to it, and I can see why. The podcast hosts, who are screenwriters, interview the CEO and product manager of Final Draft, the industry-standard software for writing screenplays — which the hosts aren’t fond of.
I don’t know anything about screenwriting, but I’ve heard people complaining about how much they hate Final Draft for years. It sounds a lot like the complaints about many other pro apps: customers dislike its design, quality, rate of progress, pricing, or all of the above.
I guess, being in the software business (sometimes), I’m supposed to identify with the Final Draft CEO. Application software faces a tough market these days, and the hosts weren’t entirely fair at times.1 But all I heard from the Final Draft CEO was an incredibly defensive, emotionally manipulative barrage of excuses and assaults against his customers. He makes his problems their problems, and any valid criticisms or hard questions are yelled down and distorted with argument-ending guilt trips about feeding his staff.
It’s quite something to hear, perfectly illustrating the dysfunction that can result from a complacent software vendor being out of touch with its customers’ needs, unwilling to listen to negative feedback, and unable to adapt to a changing market. Developers can all learn something from hearing this. And if Final Draft is a reflection of its CEO, I can certainly understand the widespread resentment.
Update: This post by a competing developer and the follow-up in the next episode are also quite good. I had no idea Final Draft was so antiquated — QuickDraw? No Unicode? — and it makes the CEO’s excuses even worse.
The hosts spent far too much time at the end berating the CEO for not asking anyone they know for feedback. But before that, their questions were quite reasonable. ↩
I love that Tim Cook has always been Tim Cook.
The X introduces a new “forked” version of Android that’s akin to what Amazon does with its Kindle Fire line. Nokia is effectively taking the open-source elements of Android and then bolting on its own services, a Windows Phone-like UI, and yet another Android app store. The downside to this is that the Nokia X devices won’t have access to Google’s Play store or Google-specific apps like Gmail, Chrome, Maps, and others. However, Android apps will run on the devices with only limited changes required by developers.
There’s a good chance this will get nixed shortly by Microsoft or simply be a market flop at launch. But there’s a small chance that this might become the most interesting mobile story of the year.
This kind of approach won’t be easy, and its success is anything but a sure thing. But I think it’s Microsoft’s only chance to break into the mobile platform business, if they still want to be in it. Windows Phone 7 and 8 have been complete failures with no hope in sight, and the sooner Microsoft can admit that to themselves, the sooner they can try another strategy — if it’s not too late.
Great post by Supertop, makers of the Castro podcast app:
The background fetch API is a game-changer for iOS developers. It has the potential to free us of significant server and infrastructure overheads. This is particularly relevant at a time when many developers are wondering how to stay independent. For Castro, the decision was an easy one and we strongly advocate that other developers take full advantage of this new API as well.
(Since I’m working on a competitor to Castro, take all of my comments here with a grain of salt.)
Service-backed apps still have a lot of advantages and exclusive capabilities over iOS 7’s Background Fetch. I think server-side crawling is still the best choice for podcast apps and feed readers, for which users want fast updates to collections of infrequently updated feeds.
Overcast has been crawling tens of thousands of podcast feeds every few minutes for the last 6 months using standard HTTP caching headers. In the last week, 62% of all requests have returned 304 (“Not Modified”). Many of the rest returned the entire “new” feed, but none of the episodes had actually changed, making the server download and process hundreds of kilobytes unnecessarily.
An app using Background Fetch needs to make all of those fruitless requests just to get the handful of occasional changes. All of those requests cost processor time, memory, battery power, and data transfer. And each copy of the app needs to download those hundreds of wasted kilobytes when a server erroneously reports an unchanged feed as new.
While a server can easily crawl a feed every few minutes without problems for either side, 20,000 copies of an app polling a show’s feed will be noticeable — and they won’t even get the updates as quickly as the server-side crawler since they’re running less frequently.
A server can simply send a silent push notification to all subscribed apps when there’s new data in a feed, and each app can download just the changes. With infrequently updated feeds, like podcasts, this leads to huge savings in battery life and transferred data over time.
I agree with Supertop that it’s important to minimize hosting costs, especially as App Store economics become more challenging, but hosting is cheaper than ever with SSDs and modern CPUs. At launch, I’ll be paying more each month for my health insurance than all of the web-hosting expenses, and I bet this will remain the case for a while.
But getting hosting this cheap requires a bit more work. You probably can’t use most cloud services, you probably need to learn basic Linux server management (it’s not as hard as you think), and you need to be a bit careful with your decisions and implementation. I’m still using VPSes, dedicated servers, PHP, and MySQL because I know how to host scalable web services very cheaply this way.1
Background Fetch is a great option, but there’s still a lot of value in a web service if you can make one.
The entire Overcast feed-crawling infrastructure can run on a $40/month Linode VPS. And Linode hasn’t even deployed SSDs yet.
To give myself more headroom for testing and the launch, whenever that actually happens (not soon), I recently switched to a dedicated server at Limestone Networks (that’s a referral link) with a quad-core Xeon E3-1270 v3, two 100 GB Intel enterprise SSDs in RAID-1, 16 GB of RAM, and far more bandwidth than I can use for $277/month.
I still can’t believe it’s that cheap. This could have been Instapaper’s master database server, which cost $1,200/month just a few years ago. I don’t think there’s a better value in dedicated servers these days than a Xeon E3 with an SSD or two. ↩
Both OS X and iOS are affected. iOS has been patched already, but OS X hasn’t — see for yourself.
It’s interesting that so much coverage of the WhatsApp acquisition by Facebook has used the same word: conglomerate.
Our industry has reached a chilling point where the biggest players are so big, with so much cash, so much to lose, and effectively zero regulation, that they can simply buy anyone who threatens their dominance.
This week: Flappy Bird hamburgers, things John likes, WhatsApp, and replacing Objective C (Copland 2010). It’s a good one.
Sponsored by lynda.com, Ting, and Squarespace.
Your mobile app loses more users on the first day than any other. Stop that. Serve up content your new users care about.
You likely already support deep links via custom URL schemes in iOS, but this only works for users who’ve already installed your app. Wouldn’t it be nice to deep-link new users to a specific spot inside your app as well?
For the first time on iOS you can do that with Tapstream’s Deferred Deep Links. They play nicely with regular deep links for users who already have the app. However, if the app is not yet installed Tapstream will hold onto the deep link. Once the install completes and the app runs for the first time Tapstream will pass back the saved deep link.
The possibilities of having “landing pages” inside your app are limitless:
Deferred Deep Links increase engagement and customer lifetime value — we’d love to hear how you put them to use.
Get started with Deferred Deep Links today, they’re 100% free.
Thanks to Tapstream for sponsoring Marco.org this week.
The new rejection language:
We found your app name attempts to leverage a popular app.
As far as I know, they’ve never done this before. Is there any chance that it will be consistently enforced in the future? The App Store has been filled with scammy clone games with misleadingly close titles to popular hits for years. This has always been one of the many App Store dysfunctions where Apple is almost entirely hands-off, to the detriment of the store, consumers, and legitimate developers.
This can be a great rule if they actually enforce it consistently. Unfortunately, precedent isn’t encouraging — the App Store has never enforced its own rules consistently.
This week: Gesture explanations, usability ceilings, Flappy Bird, Comcast, and beacon.plumbing.
Sponsored by Hover, Squarespace, and Transporter.
I wanted to take this moment to write you this letter so that you know who I am. Because I now know exactly what you are.
Candy Crush Saga is made by truly awful people. Playing it or having it installed on your phone at all is supporting this cruel, predatory behavior. Vote with your feet.
Jeff Vogel on what it’s like to put yourself out there, and what happened to Flappy Bird:
Dong Nguyen quit. A fortune coming through the door, and he walked away. …
Think about this. I mean you, personally. Think about what it would take to make you run from a gold mine like this. Really. Think about why someone would do this.
This is not about money.
Flappy Bird’s success was hilarious, but it also appears to be completely earned. I’ve read the posts suggesting he cheated at the ranks or reviews, but I haven’t seen any that supported those claims enough. Some guy in Vietnam made a primitive, crude, completely unoriginal game with cute, equally unoriginal artwork that was charming in its shittiness, frustratingly difficult, and inexplicably addictive.
A charming, comically shitty, addictive, accessible yet difficult, very casual, very quick to play, completely free game with no manipulative in-app purchases? Of course it succeeded in the App Store, fair and square.
Then so many people brutally harassed and abused the developer that he couldn’t take it anymore and deleted the number one app in the App Store in an attempt to do anything to make the abuse stop.
Flappy Bird was a cultural tragedy, and the tragedy has nothing to do with the game.