If you’ve read my blog posts about Tweet Marker over the years, including this one when introducing a paid plan, you might hear a little indecision on the right path forward. I’ve run it more like a community service and less like a business, and admittedly the window for turning it into a profitable endeavor has slipped away. But I still want to make the service work well and improve it.
After vacationing this week leading up to Thanksgiving, I finally realized I need to remove the support burden of giving out free access. Starting today, Tweet Marker will transition to a paid-only service. To make this easier, I’ve introduced a less expensive $25/month plan for smaller developers. (Previously the only choice was $75/month, which is now the top tier plan with unlimited active users.)
This solves the problem of automating access to the API. Instead of having to manually fulfill API keys so that developers could try out Tweet Marker, which usually meant weeks or months of delay until I could get to it, by signing up online, developers get immediate access to the API without having to wait on me.
In the short term, this change means that new apps must subscribe before using the API. In the long run, all existing apps should also transition to a paid plan. I haven’t set a hard deadline for existing apps yet, but will work with developers over the coming months to do so.
You can learn more at tweetmarker.net/developers/.
Update: To be clear, this post is only for developers. There's a $1/month subscription for end users but it is optional.
David Smith wrote last week on the 5-year anniversary of shipping his first iPhone app. I started following David’s work in the middle this story — after he had started the Developing Perspective podcast, but before he created Check the Weather and Feed Wrangler — so it’s especially great to see such a nice, reflective post that fills in the earlier apps. On launching and scaling Feed Wrangler:
“In retrospect, it was one of the toughest challenges and most trying times of my career. The relentless dual-pronged attack of late nights and urgent work made it crushing physically and psychologically. Now that things have settled down, I can look back and be glad that I went through it. The kind of things you learn in that kind of crucible can’t be easily recreated.”
I could read these kind of posts every day. Also last week, when Gus Mueller announced that he was selling VoodooPad, I remembered as I was talking with Daniel on Core Intuition 112 that Gus’s similar blog post from 2005 is still interesting and relevant today.
My account in Watermark right now has 805,182 searchable tweets stored in it — tweets from everyone in my timeline, App.net posts, favorites, and of course my own tweets. When I launched the service, I wasn’t sure how long I’d be able to keep storing these. I initially promised 1-2 months, then upped it to 3 months, and then 6.
Today I’m happy to announce that I have a more formal system in place for storage. The default $4/month plan will officially increase to 1 full year, storing every tweet from anyone in your timeline starting when you sign up. Your own tweets and favorites are kept forever.
If 1 year isn’t long enough, there’s a new unlimited plan for $10/month. Every tweet or App.net post in the system for your account will be kept forever. After a year or two it becomes a really massive and interesting search database, tailored just to your account.
The new tiered plans are live now for new accounts, and I’ll be rolling out a method for switching between plans for current customers soon. You can learn more about Watermark here.
The latest version of Tweet Library was approved by Apple last night. It features an updated design for iOS 7, a new app icon, and a bunch of bug fixes. I also dropped the price to $4.99, universal for both iPhone and iPad, and it’s a free upgrade for all existing customers.
The App Store screenshots weren’t updated yet, so I put together some screenshots using Sunlit here.
I’m pretty happy with how this release turned out, but there’s still more work to do. I’ll be following up this release with some additional improvements specifically for iOS 7 soon. You can grab version 2.4 from the App Store here.
Last week, Mat Honan wrote an article for Wired about App.net. It does a great job of capturing the history of App.net and why it’s different from Twitter. And it’s positive for all but the closing paragraph, which is either discouraging or a wake-up call, depending on your optimism. I recommend reading the whole thing.
Here’s what Mat says about what’s missing:
“But there’s still something missing, that seems totally obvious: a game. App.net needs a Dots or a Candy Crush or a Words With Friends that plugs into its social sphere. Something that isn’t just useful, but fun. Something wonderful.”
App.net does need a hit, a new kind of app that doesn’t resemble Twitter. If that turns out to be a game, then great. But I don’t think it has to be. There are hundreds or maybe thousands of games in the App Store that are excellent but which never made it big. The success of App.net can’t be pinned to such an uphill battle.
I do know one thing: the next great app for App.net will come from the App.net community, the developers who are passionate about the API’s potential, just as early developers like Iconfactory who took a risk on Twitter 6 years ago are still having an impact on that service today. The next great app will come from the developers who see App.net as a way to build new things.
I’m working on an app like that. It uses the App.net API, but not the timeline. It takes pictures, but isn’t really a photo app. It integrates with Ohai, but isn’t another location check-in app. It renders beautiful maps throughout, but isn’t about navigation. Some of the features I’m most proud of in the app wouldn’t be the same without App.net.
There’s no way to know what apps will resonate with the mainstream, and which will remain niche or failures. But to have any hope of success, you have to start. You might even have to take a risk on a new platform if you want to build something new.
The promise of App.net is bigger than one type of app. App.net isn’t just a blank slate; it’s an amplifier. It’s waiting to power the next new idea and help it grow into something big.
I’m launching a new paid developer plan for Tweet Marker today. It’s $75/month and includes a new admin dashboard with stats on active users, hits, and more. I’ve also expanded the API to support syncing which direct messages have been read.
Why charge developers now, after keeping the service free for 2 years? In part it’s because of something I learned from publishing the Core Intuition podcast with Daniel Jalkut. Because for the first few years of Core Intuition, Daniel and I had trouble getting episodes out very regularly; there was always something more important to work on. Adding sponsors pushed us to stick to a weekly schedule, and it’s worked out even better than I expected.
I hope the same thing will happen for Tweet Marker. Although I’ve put countless hours into maintaining Tweet Marker (and plenty of money on hosting), I couldn’t justify the effort to create new APIs because it wasn’t a revenue-generating product. Now I can dedicate more time to it, even with a modest level of support from developers.
Of course, I’m sensitive to the difficulty of transitioning from a free to paid product. That’s why I’m doing two things to make it easier for everyone.
First, I won’t be turning off any existing developers’ access to the service. The last thing I’d want is to break third-party Twitter apps currently in use. But I do strongly encourage commercial app developers to subscribe if they have the means to.
Second, I’ve created a referral program for app developers to let their customers know about the $1/month user subscription. This is a great way for developers to show their support even if they can’t subscribe to the developer plan. But even better, for developers who do subscribe, their account will be credited for each paid user they refer. This can effectively make the new developer plan free or significantly discounted.
This is a big change for Tweet Marker, but an important one to make Tweet Marker strong. I’m excited to keep working on it, so that Twitter apps can work even better together. Sign in here to learn more about it.
Nate Barham describes iOS 7 as layered glass:
“The best developers will see iOS as an operational model, not a visual one. Imagine a Tapbots app that, instead of removing the cute ‘I’m a twitter robot in your phone!’ aesthetic, doubles down on it. Zooming metal plates, ratcheting gears not shadowed from without but appearing from within the device, only now it isn’t a robot-esque layer over the stock controls, the UI becomes the character that the developer envisions—even more so than it has ever done before.”
I really like this post, but I’m not totally sold on the paragraph quoted above. Done right, it could be brilliant. But this is a very difficult thing to pull off, keeping the playful spirit of Tweetbot with a lighter, minimalist iOS 7 UI.
And related, if you missed Christa Mrgan’s recent Macworld essay, she also covers how iOS 7 will use depth and motion to switch from “faux 3D to real 2.5D”, with an example from Adobe’s After Effects. Makes me wonder if designers will need new prototyping tools.
Ben Brooks makes several good arguments for working from coffee shops:
“Coffee Shops started sprouting up everywhere in the U.S. because of massive demand for the coffee shop — not massive demand for coffee, mind you, but for the seats in the shops. This is evident with the way most shops are setup, but no more evidence needed than to look at the move of Starbucks providing free WiFi, instead of paid WiFi they started with.”
I agree. There’s no sense in fighting this trend, and the coffee shops that do will largely fail. But also, as customers, we should be careful not to abuse the privilege. I try to follow these simple rules when working from a coffee shop:
- I don’t take up more space than I need.
- If there’s a line, I usually wait until after I place my order before claiming a chair.
- For local small businesses especially, I leave a tip.
- After a few hours, I order another coffee or wrap up and leave.
Ben also points to a post from CJ Chilvers about libraries. I worked from my neighborhood library earlier this week — it’s a really nice, quiet environment — but the Austin libraries don’t allow you to bring any drinks inside yet, let alone have an on-site espresso machine. While traveling in Oregon a couple years ago, I remember the Eugene public library having a really nice cafe and I was immediately jealous.
I love this detailed write-up of the Twitter backend as it exists today. Sending a tweet to your followers uses a massive Redis cluster with a couple terabytes of RAM:
“Let’s say you tweet and you have 20K followers. What the fanout daemon will do is look up the location of all 20K users inside the Redis cluster. Then it will start inserting the Tweet ID of the tweet into all those lists throughout the Redis cluster. So for every write of a tweet as many as 20K inserts are occurring across the Redis cluster.”
A listener of Core Intuition asked me today if I had second thoughts about no longer using Twitter, especially since I still maintain a Twitter app. We’ll discuss this on a future episode, but the short answer is: no, I don’t regret it. I have a huge amount of respect for what Twitter has built at a technical level, and for the opportunities it gives people to communicate. I just don’t like their attitude toward developers.
Dave Winer writes about Doug Engelbart and the pace of changing computing systems:
“If you want to get the most out of great developers like Engelbart, who are productive well into their 80s, you have to stop digging up the streets, moving the goalposts, bombing the cities, starting over just for the sake of starting over.”
While there’s certainly a time to burn the forest for new growth and opportunity, I have little patience for those developers who spend more time breaking old code than creating new value. Maybe it’s a sign I’m getting old — that I’ve lost my taste for innovation at a technical low level — but I don’t look forward to rewriting all my working code again and again.
Very little has changed in this regard since I wrote a blog post about deprecation in 2010, which (fittingly) also linked to Dave Winer.
Rene Ritchie has a nice comparison of black and white filters in iOS 7 and third-party apps:
“To create the comparison, I took the screenshots posted on Apple.com, isolated the unfiltered image, loaded it into the other apps, applied their filters, and then took screenshots of the resulting images.”
I've been working on an iOS 7 app that's partly about photos, though not actually a camera app, and I always thought it'd benefit from a single great black and white filter. Not as one of a dozen filters, but as the only filter in the app — something strikingly different that would be noticed. iOS 7's built-in filters and apps like Camera Noir have made me reconsider. Why reinvent the wheel when so much good work is being done on filters by other developers?
Related, the excellent mobile photo workflow by Rands.
“We spend a lot of time on a few great things.” — Designed by Apple in California
In 1940, Ub Iwerks, the animator behind Walt Disney’s first Mickey Mouse shorts, came back to the Disney studios after a 10-year absence. Ub had famously produced hundreds of drawings alone each day for one of those first Mickey Mouse shorts, but Ub’s return to Disney would also be remembered for his contribution to the technical side of film production, with advances in cameras and special effects. In an industry with extreme specialization — you either did backgrounds, or animation, or ink-and-paint — Ub’s talents bridged both the artistic and technical.
One of Ub’s inventions while away from Disney was called the multiplane camera. Perfected by others leading up to Snow White, in a massive camera stand over 10 feet tall, the multiplane’s innovation was to allow a background to be split into levels. Foreground trees might be painted on the glass of the first level, then the characters sat underneath that, and then farther back layers for a building, with others behind that for hills and sky.
To provide a sense of depth, camera operators could vary the distance between each plane. And movement for each level could be synchronized at different speeds, giving it a beautiful parallax effect. Distant background levels moved more slowly and were naturally blurred and out of focus.
80 years after Ub’s invention, the multiplane is alive in iOS 7. Previous versions of iOS were built on a single plane with raised and textured areas on that surface, like a topographical map except with buttons instead of mountains. iOS 7 is instead designed with multiple flat layers. Each level is strikingly flat, but by layering two or three, spaced apart, Apple has achieved an overall sense of depth.
It’s a return to basics. Simple things can remain simple, readable. When clarity is needed, everything goes flat. But it’s a framework that allows for subtle motion and depth without changing what works about the new, content-first flat design. iOS 7’s control center blurs the layer below. The home screen background sits deeper too, as if only the app icons are touching the screen. Photos scroll under the navigation bar.
Each plane is painted flat as if on glass. There can be no text drop shadows, no textures, without ruining the effect. And the result of this strict metaphor is equally valuable: there are no drop shadows to distract or obscure an app’s real content.
Disney’s multiplane camera, first in a dedicated rig and then recreated in software, lasted for decades, until the era of 3D computer animation. iOS 7’s new look won’t last that long, but the core concepts should carry Apple for years. I really like where they’re headed.
I have big news for Searchpath today. The client-side portion of Searchpath is now officially open source and available on GitHub. While I do think one of the innovations of Searchpath is the JavaScript, CSS, and HTML, it’s really the simplicity of setting up Searchpath that makes it work. A single line of JavaScript adds a search box and indexes your site, and the crawling and storage will of course remain private on my servers.
Now that part of the service is on GitHub, customers who wanted to extend the JavaScript can have a clear path for doing that. Not only is it easier to host the JavaScript yourself, but I’m accepting pull requests to integrate your improvements back into the core product for everyone to use. Special thanks to Brett Terpstra for already submitting some tweaks.
I’m also very excited to announce a simple themes structure for Searchpath. Because in addition to the JavaScript, the second part of customizing Searchpath is the design. While I document CSS class names you can use to override styles, I wanted to make it even easier to design completely new user interfaces and share them with others.
On GitHub you’ll find a “themes” folder. Any sub-folder here will be routinely synced to the main Seachpath server, where you can access it by adding “theme=folder_name” to the JavaScript include URL. To create your own theme, just add a sub-folder with your own custom theme name and submit a pull request. When the theme is added to Searchpath, all your CSS and images will be hosted by my servers. (The first person to use a specific name will effectively become the owner of it, and I’ll only accept pull requests from that person.)
Want to learn more about Searchpath? You can try it out here for free, or sign up for $8/month.
Ahead of WWDC, Apple dropped the 4th-generation iPod Touch from their lineup and replaced it with a slimmed down $229 iPod Touch. To achieve this lower price, they made a big sacrifice: no rear-facing camera.
Most surprising to me is that this change comes just weeks after the iPhone’s Photos Every Day commercial, one of the most beautiful ad campaigns Apple has ever run. Removing the camera from the iPod Touch transforms it from a peer of the iPhone, capable of the same kind of photos and videos, to nothing more than a game and internet device. It is the only shipping iOS device that can’t be used as a traditional camera.
As we know, people frequently use even the iPad as a camera, holding it up to take pictures at concerts, their kid’s basketball game, and at any family gathering. When all you have is a cheap phone, you absolutely want to use the iPad as a camera, because it means you can sync and share the photos.
My daughters have the older, smaller-screen iPod Touch and frequently use the camera with friends. Instagram, in fact, has become very popular with teens and pre-teens. Can you imagine how great it would be to have grown up in the 1980s, for example, with the ability to take essentially unlimited photos? Angry Birds may have taken the mobile spotlight when iOS went mainstream, but in a dozen years when these games are just a fun memory, we’ll still have some of the JPEGs, first-hand accounts of life in middle school.
I’m sure dropping the rear camera was a very tough decision for Apple, especially thinking about wanting more memory and speed to run iOS 7. But I’d rather have no FaceTime, slower CPU, less memory, and only 8 GB of storage any day of the week if it meant I could take photos. The rear camera is priceless.
Today is the 5th anniversary of Core Intuition. I’m really proud of what Daniel and I have been able to do with it. In our first episode, we set up a basic structure for the show — the length, segments, and theme music — and we’ve stuck to it for 91 episodes.
About the only significant change was when we added sponsors last year, allowing us to take the podcast weekly. Since then we’ve actually recorded the bulk of the episodes. Sponsorships pretty easily exceeded my expectations, and I’m very thankful to all the small and large companies alike who have helped support the show.
Today’s episode covers my recent server move to Linode, which I’ll write more about here later, and a question about the mix of developers at WWDC. Maybe it’s fitting that our first episode was also about WWDC. I like that every year, when the podcast gets a little older, the timing works out such that we’ll likely be revisiting similar, pre-conference topics. Because these couple weeks, leading up to and including WWDC, really define the best part of being a Mac or iOS developer.
