Are you still using pictures and videos to market your app? Are you not getting the downloads or exposure that your app deserves? Then it’s time to try a playable demo instead!
At App.io, we enable your native iOS app to be playable in any browser. No plugins or downloads, just click and play instantly. It’s super easy, embeddable anywhere, and takes less than 30 seconds to enable your app.
This is good, but the biggest problem I always have with Siri is reliability, not quality of answers.
I’ve consistently been getting the “Sorry, I can’t take requests right now” failures on almost half of the requests I’ve made in the last year or so. It fails so often, and failures are handled so poorly, that my Siri usage has dropped from almost daily to once or twice a month. By this time next year, I bet I’ll suddenly realize I haven’t used Siri at all for months.
When ElevationLab first started promoting the Elevation Dock 2, I thought the name seemed a bit misleading: as far as I could tell, it was just the original Elevation Dock bundled with the Lightning adapter and something called “NanoPad” to help it grip the desk a bit better, which I figured would work about as well as most non-skid rubber sheeting.
The original Elevation Dock’s major problem was its huge production delay, followed by Apple releasing the iPhone 5 with the brand new Lightning connector right as most Kickstarter backers were getting their docks. Rather than go through the lengthy and expensive process to build an officially licensed Lightning dock with a custom connector, ElevationLab rushed to release a quick fix: a little clamp that mounted Apple’s stock Lightning cable into the existing Elevation Dock.
It sucked, mostly because the cabled Lightning connector requires too much force to remove: enough effort to remove the phone would also lift the Dock right off the table, ironically giving it the same annoyance that ElevationLab made fun of in their original Kickstarter video. It was a beautifully manufactured, high-quality dock that didn’t work very well.
In the meantime, I switched to another Kickstarter heavy-dock project, the Dock+. It works decently, has a real low-friction Lightning connector, and charges iPads as well, but is sloppily made and a bit ugly.
Today, I got these in the mail from Casey Hopkins of ElevationLab, unprompted:
Naturally, I accepted the challenge.
I also took its description of having “thousands of microscopic suction cups” as a challenge for my macro lens:
To the naked eye, it just looks like a flat, black, shiny surface. The holes aren’t visible at all. “Microscopic” might be a bit of a stretch — my macro lens isn’t that good — but to give you an idea of the scale, it looks like the holes are roughly the size of the aluminum dents from bead-blasting, which are small enough that the surface looks and feels perfectly smooth in reality. (The very slightly misaligned pad on the metal base is my imprecise installation, not ElevationLab’s.)
Photography verified that the NanoPad is indeed cool. But most important is how it works.
And it works incredibly well.
Assuming the NanoPad was like typical non-skid material was a gross underestimation of its grip — it’s more like a strong adhesive, although it comes off cleanly and reattaches easily. It works exactly as promised, and ElevationLab is not exaggerating with any of its claims.
In fact, it’s so good that I might buy a few extras to adhere other objects to desks, tables, and counters.
None of this makes the Elevation Dock’s Lightning compatibility less of a hack. Now, it’s another hack on top of the previous hack, but this hack actually works. You still need to supply your own Apple Lightning-to-USB cable, and it’s still an inelegant, high-friction connection — the NanoPad just makes it a one-handed operation.
Despite the hackiness, that’s a substantial improvement. Before the NanoPad, the Elevation Dock worked so poorly with Lightning that I stopped using it entirely. Now, I’m back to it. For $7, I definitely suggest that Lightning-adapted Elevation Dock owners give the NanoPad retrofit a try.
For new buyers, it’s less persuasive: you’re still looking at spending at least $90 for the dock, plus losing an Apple Lightning cable and AC adapter to it (or buying extras from Apple for a total of at least $38). It’s a tough sell.
It’s a pile of hacks, but it works, and it looks much nicer and is better made than other docks I’ve seen and used.
Driving app downloads is getting more expensive every day. Advertising costs can easily exceed a customer’s lifetime value. How do you get more app installs without breaking the bank?
Fact: Only 6% of iOS users find apps through advertisements. (Forrester)
Fact: Outside of the App Store, the dominant sources of app downloads are social media, web browsing, and search. 20% of iOS users find apps through social channels alone. (Forrester)
If your app marketing doesn’t include these channels, you’re missing a huge potential source of new users. Tapstream lets you send visitors to your app from Twitter, Facebook, email, blog posts, comments, or anywhere else links can go. You’ll find out exactly how many people click on each link and how many of those install your app. Most importantly, you’ll see the engagement and revenue broken down by each channel. All for free!
Like any other in-app purchase, customers can start an auto-renewing subscription within your app.
But they can’t end it. There’s no way for developers to offer an “Unsubscribe” button, and the actual App Store subscription management page is buried where few customers ever think to look.
Naturally, customers who can’t figure out how to unsubscribe don’t get angry at Apple — they blame the developers, writing angry 1-star reviews and nasty support emails because they think we’re trying to rip them off.
We can’t help them in response, because developers can’t even cancel their subscriptions — only the customers can. Developers can only apologize and refer them to this Apple support document.
When a new customer subscribes, the system in-app-purchase dialog pops up to confirm (…eventually — it’s so slow that it’s easy to assume it failed and tap again). Then a second box comes up with the dreaded “share your information with the publisher” dialog, which has its own problems.
The new-subscriber process is mediocre, but it’s much better than when an existing subscriber needs to sign in on another device.
By convention and policy, apps should display a “Restore Purchases” button. If a subscriber invokes it, their subscription is (…eventually) restored properly.
If they instead select “Subscribe” again, the subscribe flow works as usual, but ends early with a dialog telling the user that they’re already subscribed. Fatally, this is reported as a failure to the app, and there’s no way to distinguish between an “already subscribed” failure and any other subscription failure, such as a failed login or hitting Cancel.2
As you can imagine, this causes yet more support email and angry 1-star reviews. And when apps do it wrong — which happens frequently, especially since sandbox testing is difficult and Apple’s reviewers don’t test for this — it causes embarrassing bugs that prevent people from using the subscription they’re paying for.
There’s no way for developers to know for sure when an auto-renewing subscription will end. When a customer toggles “Renew automatically” to “Off”, that isn’t reflected in the API. The subscription continues through the current period, and there’s no way to tell when it will end until it actually ends.3 And, of course, we can’t end it manually.
Developers also have no way to extend a subscription. And nobody — developers or customers — can buy or redeem subscriptions as gifts.
This complicates support and marketing. Developers can’t, for instance, give free subscriptions to reviewers or extend a subscription to appease an angry customer.
These limitations can be avoided by having a separate website payment and subscription system. (Use Stripe.) Then you can give reviewers web subscriptions, enable gift purchases, extend subscriptions arbitrarily, cancel subscriptions yourself, and provide much more helpful sign-in feedback in the app, all while paying much lower commissions.
But in an iOS app, you must offer subscriptions via In-App Purchase. Web and in-app subscriptions can coexist without too much trouble, but it becomes problematic when an in-app subscriber wants to convert to a web subscription to get one of its benefits (redeeming a gift or extension, etc.). Since you can’t cancel an in-app subscription, detect when it will end, or even verify whether any given email address is a subscriber,4 it’s difficult to coordinate the switchover.
What are all of this complexity and all of these limitations supposed to buy?
In theory, it’s easier for customers since they don’t need to renew manually after each period. But it’s much harder to restore purchases and cancel subscriptions, so I’m not sure it’s a net win for them.
The real appeal is clearly lopsided to benefit the developers:
“Free” money from accidental renewals: There’s certainly some of this, but it’s ethically questionable. It also has potentially unforeseen costs: how will it affect your business if your customers resent you for taking money from them every period until they remember to go through the clumsy process of canceling?5 How much will it cost you in guilt, 1-star reviews, support emails, and lost loyalty when you try asking the audience to check out something new?
Reliable income: Again, there’s some of this, but it’s not as reliable as you might think. Like any other subscription, you’re going to lose some subscribers in every period, and you’re going to need to attract at least as many to make up for the loss.
Subscriber information for direct marketing or selling to third parties: If your business model depends on this, I can’t help you — we’re in two very different worlds. I’d really rather not get people’s names and home addresses — that’s a pretty big liability that I don’t want — and I only want emails so I can send password resets and maybe an occasional opt-in newsletter.
What I built for Instapaper instead was much simpler.
I used the old “non-renewable subscription” in-app purchase type, which is almost a misnomer — it’s simply buying access to something for a fixed duration. I also offered the same subscriptions on the website through PayPal with recurring billing. (That was a mistake. Never use PayPal for recurring subscriptions.6 Use Stripe.)
The non-renewable in-app purchase enables your subscription for an additional 3, 6, or 12 months.7 Two weeks before a subscription expires, the app shows one dialog informing the user of this and offering a renewal. Three days before, it shows one more. And after it expires, it shows one more. That’s it.
It had almost the same loss and renewal rate as the auto-renewing PayPal subscription, but with nearly zero support cost. It was great for the customers, Instapaper, and Apple.
Implementing non-renewing subscriptions is simple, too: every user has a subscription expiration timestamp. When a purchase comes in, validate it and simply extend the user’s expiration date into the future by that interval. It’s night and day compared to implementing and supporting Apple’s auto-renewing subscriptions.
Offering non-renewing options and a good auto-renewing system, like Stripe, is a nice balance. But if your choice is between non-renewing subscriptions or a bad auto-renewing system, such as PayPal’s or Apple’s, you’re better off not using auto-renewing subscriptions at all.
Building a non-Newsstand app with the expectation that you’ll be permitted to use auto-renewing subscriptions is still a big risk, though.
The most common case I see is developers who want to fund a web service with them. While Apple has permitted some services to bill with auto-renewing subscriptions, it hasn’t been consistent — I still hear from people who have been rejected for attempting it. Even if you get approved, anytime you’re on the edge of a policy like this, there’s a good chance you’ll be rejected or required to remove it in the future. ↩
In an early version of The Magazine, I tried evading the “already subscribed” problem by quietly invoking a restore-purchases before every subscribe attempt. It worked well in most conditions, but had a few awkward edge cases. Shortly after releasing it, Apple required that I remove it because it used In-App Purchase in a “non-standard” way. ↩
Well, you don’t know a subscription has ended until you poll Apple’s API for an update. Apple doesn’t support automatic notification to a callback on your servers, so you just need to poll them to revalidate every subscription on some interval, generally daily or weekly. ↩
The “share your information with the publisher” report includes names, emails, and addresses, but does not include transaction IDs. There’s no way to tell whether someone with a given email address is a current subscriber or when their subscription ends.
So if you have a website, you also need to build and support a method for people to claim and connect their in-app-purchase subscription to their website account. ↩
Apple does send an email to subscribers a few days before each renewal. You’d think this would alleviate the “you’re taking my money, I don’t understand what this is for, I demand you stop immediately” emails, but in practice, it doesn’t. Many people apparently either don’t receive them, don’t read them, don’t understand them, or simply don’t remember them. ↩
This could be its own entire post. The quick version: the website becomes unusably slow with lots of small transactions, issuing refunds is time-consuming and tedious, non-PayPal-account customers can’t cancel their own subscriptions, disputes are handled as if everything’s an eBay item you didn’t ship, the payment notifications to your servers are unreliable, and there’s no way to get a list of all current subscribers in the API or otherwise (really!), which makes it impossible to rectify inconsistencies caused by the unreliable notifications.
Trust me. Use Stripe. The loss of buyers without credit cards is completely worth the massive savings in support email and headaches. ↩
There were no savings for buying more time — it was simply $1 per month. I thought nobody would buy the biggest option (12 months). But interestingly, while almost nobody bought the middle option (6 months), the 3-month and 12-month options consistently grossed almost the same amount each day. ↩
Whereas the Newsstand in previous version of iOS looked like a bookshelf hosting a row of magazine covers, the new version is opaque, showing only a diagrammatic representation of generic magazine covers.
… But what’s worse for publishers is that there is now no visual reminder within the Newsstand icon that there are publications inside, waiting to be read. On top of that, in iOS7 users can now hide the Newsstand icon inside a folder. The once-special treatment that Apple gave publishers in order to encourage the distribution of magazines to the iPhone and iPad had apparently vanished, at least in terms of visual prominence.
The problems with Newsstand go even deeper on the technical and economic side:
Auto-renewing subscriptions, which launched as effectively Newsstand-exclusive, are now permitted in any app that sells content or services that fit within Apple’s (vague, arbitrary, and capricious) permitted categories for auto-renewal.
Background downloads and silent content-available push notifications could only be used in Newsstand apps prior to iOS 7. But under iOS 7, these are available to all apps.
Adding insult to injury, the new NSURLSession background-download system is much better than Newsstand’s old NKAssetDownload system, and during the iOS 7 beta, Newsstand developers were told to stick with their old system and not use the new one.
I see no benefit to magazines being in Newsstand anymore. Newsstand apps now have no meaningful exclusive abilities, and iOS 7 effectively buries them in a bland, opaque folder that’s easily hidden.
I don’t think there’s a good way for existing Newsstand apps to leave it without losing all of their subscriptions, but if I were making a new publication app today, I’d stay out of Newsstand and just make it a regular app.
Wired can’t find any evidence that “burn-in” actually changes the sound of speakers, headphones, and microphones, concluding:
Indeed, all of this variation gets at the real thing people are reacting to when they buy new head- and earphones: mental burn-in. If you’re used to dark-sounding headphones, neutral ones may sound bright at first until you get used to the new sound. That flexible calibration is how many of our senses work. Light seems brighter after darkness, sound rings louder after silence. Chances are, a lot of what people attribute to headphone burn-in is actually just their brains gradually becoming used to this new sound or new setting.
I think this is exactly right. I’ve never noticed any effects of burn-in on any of my audio equipment — excellent equipment sounds great on day one, and underwhelming equipment never becomes more… whelming over time.
(At the much higher end, the excellent but openBeyerdynamic T90 is on sale for almost $100 off its usual price. It’s a shockingly good pair of headphones. Full review coming soon.)
Also worth noting: the Big Jambox is on sale for $250. I’ve owned or tried a handful of Bluetooth and AirPlay speakers, and the Big Jambox is the best by far. I just bought another one. Here’s my review, especially compared to the Bose SoundLink (which I hated) and regular-sized Jambox (which I don’t recommend anymore). For whatever it’s worth, to me, it looks best in white.
Update: Great prices on my favorite portable sets for walking, commuting, or traveling, too: closed (recommended) and open.
This is everything wrong with tech-startup culture, unreasonable expectations, and workaholism in one job posting, by a company with a massive audience that probably contains a very high percentage of young software developers.
They would like someone with a computer science degree and at least three years of professional experience in developing web apps top-to-bottom on the full PHP/MySQL stack and Java, Python, or Ruby development1and high-traffic server and database administration and supporting their other employees’ local office IT needs.
They’re going to require you to be a workaholic, not having any work-life balance, which they flippantly celebrate and glorify.
They don’t specify a salary, but they’re very clear that it’s going to be very low — they’d rather spend a fraction of the difference making the office nice.
I did almost this exact job for Tumblr’s first four years. I required, and was given, a great salary plus stock, a nice office environment, and a healthy work-life balance. The difference is that I didn’t have much experience going in — I learned most of the scaling side as we went. An advanced web developer who also wants to be a sysadmin and already has experience managing high-traffic infrastructure is very rare and far more valuable.
Penny Arcade wants one of those so they can pay them a low salary and burn them out. The candidate is expected to be happy and honored at the privilege of this terrible deal.
Their unreasonable, immature expectations are a damaging message to send to their huge audience of young software developers. Yes, there are other employers this bad (and worse) in the industry, but you don’t have to work for them. There are a lot of better options, especially if you satisfy even half of Penny Arcade’s requirements — and a healthy work-life balance is a basic requirement, like your paycheck, that you shouldn’t tolerate losing for any employer.
Bonus points for not knowing that PHP is an object-oriented language. ↩
With the new Mac Pro’s release imminent, it’s important for prospective buyers to understand the odd-looking CPU options:
It looks like you’re paying a lot for slower clock speeds as the cores increase, but that’s not the entire story. Those weird Turbo Boost numbers, which are easy to pull from here and here, are worth understanding before choosing a modern Intel processor.
They indicate the number of extra 100 MHz increments by which the CPU may ramp up its speed with a given number of cores in an active, high-power state. The sequence begins with all cores active, then counts down to just one core active. For instance, the 6-core’s increments are “(1/1/2/2/2/4)”, which means:
1 step (+100 MHz) with 6 cores active
1 step (+100 MHz) with 5 cores active
2 steps (+200 MHz) with 4 cores active
2 steps (+200 MHz) with 3 cores active
2 steps (+200 MHz) with 2 cores active
4 steps (+400 MHz) with 1 core active
This is probably a more helpful way to compare:
Maximum Turbo GHz Per Core
(The two red entries — the 6-core E5-1660 v2 and 8-core E5-2667 v2 — are not available in the new Mac Pro, but I wish they were. Faster, the same TDP, and the same or larger cache, for a few hundred bucks more.)
This is why the AAPLJ90,1 Geekbench results make sense: the single-threaded performance on all but the 12-core is effectively identical, and the 6- and 8-core’s multithreaded results scale almost perfectly linearly with their respective core count despite an advertised 500 MHz base clock difference.
You can also see why I don’t recommend the 12-core model to anyone except those whose software will definitely make very good use of all of its cores, at least most of the time — because for any other conditions, it’ll be slower than the others.
Turbo Boost is also why the iMac and 15” MacBook Pro are matching the new Mac Pro already in single-threaded benchmarks, why the 15” MacBook Pro is so much faster than the 13”, and why the Air can keep up despite a much lower base clock speed:
13” MacBook Air 1.7
13” RMBP 2.8
15” RMBP 2.6
27” iMac 3.5
Mac Pro 4-core 3.7
Maximum Turbo GHz Per Core
So why buy a Mac Pro for CPU performance at all?
The increased L3 cache helps certain workloads, but the biggest difference is the TDP, which specifies the maximum sustained heat output of each CPU.
Turbo Boost can only sustain its higher speeds as long as it’s being adequately cooled and is under its TDP limit. This is why the clocks decrease as the core count increases: since all of the Mac Pro’s CPUs have the same TDP, Intel can’t just offer a 12-core that can sustain 3.9 GHz.
While the MacBook Air can match the 13” MacBook Pro’s clock briefly, it won’t hold it for as long because it can’t afford the heat. Those giant 130 W TDPs in the Mac Pro can accommodate much more than the laptops and iMac under a sustained heavy workload — especially if the CPU is being stressed but the GPUs aren’t, due to the shared-giant-heatsink design. (And if the GPUs are being stressed, the Mac Pro should be justifying itself quite well already.)
But there’s little reason to get the higher-end Mac Pro CPUs unless you know you’ll use all of the cores. And if you won’t be sustaining heavy parallel loads and you won’t take advantage of heavy GPU power, there’s a lot less reason to get the Mac Pro at all.
Take pride in your app stability. Building high-performing apps just got easier.
Introducing Crashlytics, the world’s most powerful, yet lightest-weight crash-reporting solution. We perform a deep analysis of your stack traces, highlighting the most impactful threads and lines so you can spend more time fixing issues and less time finding them!
Crashlytics seamlessly integrates within seconds for iOS and Android, and is trusted in many of today’s top applications, including Twitter, Square, Yammer, Yelp, Waze, PayPal, and many more.
One of my favorite writers, Dan Rutter, explains and dissects many audiophile claims in discussing Neil Young’s proposed Pono platform:
The big deal about Pono is, of course, that 24/192 audio is meant to sound better even than CD, let alone lossily-compressed MP3s or AACs. According to Neil Young, digital-music listeners today, who are almost all listening to music data-reduced via MP3 or some other lossy codec, are as a result enduring sound worse than that from a 78-RPM shellac record.
And actually, I think that from his own point of view he may be right, in a way. But the only way for him to be right is a terrible one, that leaves me wondering if everybody else is just humouring this old guy with a large wallet.
Matt Gemmell on how we view and use multiple computing devices today:
I don’t think we take enough time to assess whether we’re unconsciously opting into constraints that don’t really need to exist.
At the end of last week’s ATP episode, I ranted about people going iPad-only for workloads that laptops are much better suited for. This is along the same lines, but better said: if you have the ability to own multiple tools, use the right tool for the job.
If your work can’t be done on an iPad without jumping through hoops and bending over backwards, it’s probably the wrong tool for the job.
The portability and battery-life gap between an iPad and a MacBook Air has never been smaller. This is a great time for iPads and Macs. If you’re reading my site, there’s a good chance that you don’t need to choose just an iPad for your computing needs.1 Nobody’s pressuring you to go iPad-only. The laptop isn’t going away.
If your work fits gracefully into an iPad, then great — you have options. But if it doesn’t, don’t force it.
If you can’t afford both an iPad and a laptop, and you’re technically proficient enough to enjoy my site, you probably shouldn’t get an iPad at all.
You’d probably be better served getting a laptop (as your only computer) first, a smartphone second, and maybe an e-ink Kindle if you want a bigger screen for portable reading. ↩
A Medium post by Alicia Liu on Medium. Did I mention this was on Medium?
To me, it was just another marketing gimmick, like so many corporate-sponsored hackathons before it, to trick otherwise sane developers into working for free—with copious amounts of junk food and caffeine and the lure of dubious prizes—to develop apps on top of APIs and platforms they otherwise wouldn’t bother with.
Turns out her suspicions, which were published on Medium, were correct. But Salesforce’s execution was much shittier and sleazier than most people would have predicted. See the Hacker News comments as well.
While Salesforce got a bunch of free ideas out of this, they also burned the developer community badly, which is going to hurt their recruiting (and maybe retention, too). I can’t imagine this will prove worthwhile in the long run.
I wonder how Mattt Thompson feels about the company he works for now, after he spent some of his immense credibility to promote this event. I wouldn’t hold it against him — I’m sure he didn’t know this would happen — but he should sure hold it against them.