info
Why are third parties important in the Twitter ecosystem?
Let Twitterrific count the ways:
And more.
Updated January 19th, 2023:
7. First app to leave the App Store.
Dear Steve,
First, let me congratulate you and everyone at Apple on the release of the iPad. From my dealings with your company, I know it wasn’t easy. Thanks to everyone for busting their asses: a lot of very complex puzzle pieces came together during those last 60 days!
I recently had an encounter with Bill Atkinson. I told him that “I haven’t had this much fun with a computer since 1984.” He laughed, said “Thanks!”, and went back to working on his iPad app. We, and many other developers like us, are completely smitten with this new device.
After owning an iPad for a little over three weeks, it feels like we’re dealing with something much bigger than that Mac we all got excited about over 25 years ago. I’ve been struggling to define exactly what that is: beyond the technical specifications like the beautiful screen with its large multi-touch surface. Those specifications define what the device can do, but not what it means in our lives. I want to understand the magic.
Last week, much of that meaning came into clearer focus at a birthday party for my brother, niece and nephew (April is birthday month in our family!) My wife had loaded our iPad with photos from a recent trip to see the desert wildflowers in Anza Borrego and my 50th birthday party from the week prior.
Predictably, people’s initial reaction was “Wow, that’s the new iPad!” But that quickly faded as I opened the Photos app and passed the device around. My family was more interested in sharing the photos than talking about the new technology.
I was particularly interested in how my mother, the quintessential technophobe, would react to the device. She picked up on things quickly and was flipping through photos in no time. It astonished me how the interface disappeared for her: at one point she subconsciously licked her finger before “flipping” to the next photo.
As interesting as it was to see someone non-technical use the device, the real eye opener was how several people could interact with the iPad at once. Much of my mother’s fear of computers was overcome because she was looking at the pictures alongside my sister-in-law who helped her out when she got stuck. Learning was organic.
My niece also discovered some of the games I had on the device. One, Abca, was a hit because many people could play it at once. I’ve always played the game by myself and was surprised at how much fun it was to have other people guessing words simultaneously. A group of people transformed the software into something no developer had ever expected.
All of this led to the revelation that we’ve begun a new age of “communal computing.” The desktop revolution centered around empowering individuals: this new revolution will extend that empowerment to groups of people.
The iPad was naturally passed around amongst the partygoers. Many people interacted with it during the evening, and I lost track of who had it at any given time. And therein lies a fundamental problem.
My iPad has a lot of personal information on it: email, business documents, and financial data. When you pass it around, you’re giving everyone who touches it the opportunity to mess with your private life, whether intentionally or not. That makes me uneasy.
It’s hard to fault Apple for this shortcoming. The secrecy of the project undoubtedly limited the amount of group interaction your designers and engineers would experience with their new creation. The social aspects of this device is probably just as much as revelation to them as it is to me.
I can envision several ways to solve this problem: either with a traditional login screen or with something new like folders that require a passcode to open. I have no doubt that your designers can find something elegant that gives me peace of mind as I share my iPad with friends and family.
Thanks for your time and consideration,
Craig Hockenberry
Updated April 30th, 2010: I filed Radar #7922808 for this issue and it was marked as a duplicate of Radar #7584426.
Here we are on the brink of a new iPhone OS product introduction and developers are facing yet another crunch with device IDs for Ad Hoc testing.
Apple currently lets each iPhone developer, whether a company or an individual account, assign 100 devices for testing purposes. A large chunk of those available devices get used by employees with multiple devices. We also have a valuable group of external testers that we use for Ad Hoc beta testing. Many of these individuals buy the latest and greatest hardware, so each time there is a new product introduced, we use up more devices from our list.
On April 3rd, almost everyone on our beta test list will be buying an iPad and want to run Twitterrific on it. Unfortunately, some of these testers are going to be out of luck because we don’t have enough devices left to allocate. I have no idea what we’re going to do if the next version of the iPhone OS is introduced before our iPhone Developer account gets renewed.
As a developer, I never like turning a valuable tester away from my product. But that’s what we’re doing now.
To be clear, I think Apple’s policy is justified. Developers were abusing the system, so something had to be done. The problem, in my mind, is that the throttling valve is being put on the wrong piece of pipe.
As developers, we want to maintain a pool of testers, not devices that they test on. Devices are ephemeral: they change as new hardware is introduced and replaced. The thing that remains constant are the people who test our products.
A tweet from Mike Piontek crystalized this thought: the limitation for Ad Hoc provisioning should be based around individuals, not the devices that they own. It makes more sense to regulate Apple IDs rather than UDIDs. I want John Gruber to be able to run my apps on whatever devices he currently owns. I want to put my own name on the provisioning list and enable the five iPhone OS devices sitting on my desk. All that Apple cares about is that are only 98 other people besides Gruber and me.
(I suspect that Enterprise IT has similar problems and would welcome a solution based on employees rather than the hardware they own. I can only imagine the headaches of managing thousands of devices.)
Of course, there’s a huge amount of infrastructure around verification based on UDIDs: the Program Portal, device firmware, and our own internal processes would require changes. But I think it’s a good goal to work toward, because the current system isn’t scaling well and will only get worse as Apple introduces new products.
Updated April 13th, 2011: It’s been over a year and the situation just keeps getting worse. Please take a moment and duplicate rdar://9255432. Thanks!
In spite of plenty of advance warning from Twitter, we got caught by the Twitpocalypse bug.
For the 2.0.1 release, we had tested our software extensively. I actually wrote an emulation layer on top of the code that reads data from Twitter that added a large number to every ID read from Twitter. This testing uncovered several bugs which were fixed and incorporated into the MGTwitterEngine open source code.
Unfortunately, this testing didn’t take into account that the library we use to parse the data (YAJL) includes a range check that ensures signed values, which are allowed by the JSON specification, will fit into 32-bit storage. The “YAJL Error 3” is that library telling us that the range check failed.
In hindsight, I should have fed the parser some large unsigned integers. In the wonderful world of software development, we call this a brain fart.
Unfortunately, the Twitpocalypse occurred on Friday evening, just as my wife and I were heading out for a high school graduation. I quickly shot off an email to Twitter asking a few questions (I had mistakenly thought that there were problems with data being returned by an authenticated connection.)
After a couple of hours of iPhone email and SMS, it was clear that we were going to need do a new release. We had a critical bug that affected thousands of users. And our fear was this submission would take longer than normal: many developers are submitting 3.0 updates.
Life officially sucked at this point, and the graduation ceremony was memorable for all the wrong reasons.
After getting a few hours of fitful rest, I opened up Xcode on Saturday morning and started looking for the problem. It took just a few minutes to find the bug and another few minutes to fix it. Our concern at this point was getting the update to users.
In spite of it being the middle of weekend after a busy week at WWDC, we were able to get in touch with Apple Developer Relations. Our contact was able to expedite the approval of the application.
To say that this was a relief would be the understatement of the century. The update for the free version started showing up in iTunes on Sunday evening. The paid version was updated on Tuesday morning.
Developers are human. We make mistakes. It’s interesting to note that Loren Brichter and Buzz Anderson, fellow developers whose skills I hold in high regard, were also affected by the Twitpocalypse. It really does happen to the best of us.
It’s also interesting to see that Loren and Buzz reacted in the same way I did: by fixing the problem ASAP. In Loren’s case, that meant finding a hotel with WiFi in order to distribute his update. Buzz released a new beta in a matter of hours.
In my experience, these brain farts are problems with easy fixes. It’s something like checking for invalid bounds, getting a Boolean state wrong, or something else of that nature. It’s not a complex problem: it’s an oversight.
The problem, therefore, is not how fast we can react to fixing critical bugs, but how fast the App Store reviewers can react with an approval.
As a device that’s constantly connected to the Internet, the iPhone taps into a stream of data that is unpredictable. Data in “the cloud” can change at any time, and web applications naturally adapt to these changes with a quick deployment strategies. Those of us who are building client applications on top of this network infrastructure need the ability to adapt quickly, too.
Security issues are another area where a quick response is a requirement, not a luxury. If I discover something that puts a user’s private data at risk, it’s my responsibility to fix the problem as quickly as possible. Time spent in a review queue is time spent being exposed to a flaw.
At the same time, we shouldn’t blame Apple for these delays in reviewing applications. In the year that they have been selling our products, the App Store has been more successful than anyone imagined. It’s clear to me that reviewers and others involved in the approval process are overwhelmed by this success.
Fortunately, I think there’s a simple way to solve this problem for all developers selling products on the App Store. The inspiration for this solution will be obvious to anyone who’s used Apple’s Developer Technical Support (DTS.)
When you purchase an ADC membership, you are given a number of “incidents”. These DTS incidents can be used when you have a problem that can’t be solved through documentation, support forums or hours and hours of debugging. It’s for the hard stuff, and usually involves getting an engineer at Apple involved to understand and fix the issue.
As a developer, I’m very careful to use these incidents wisely: they are a last resort. There are some years where I don’t use them at all, those are the good years.
A similar system could be put in place for critical bug fixes on the App Store. If every developer was given one or two “prioritized reviews,” it would act as insurance for the brain farts. You’d have a way to raise a flag and say “I need special attention for a critical bug.”
If another developer has a critical bug, I have no problem with my review process for a feature release taking a little longer. And since prioritized reviews would be a scarce resource, they won’t be open for abuse because developers will think twice before using them.
Because it’s not a matter of if you have a brain fart that leads to a critical bug, it’s a matter of when.
The general consensus is that there will be a new iPhone announced next week. I, like others, think it’s going to have new features and capabilities. But how is Apple going to label this new device?
It’s entirely possible that Apple will keep the same name as the previous version. There’s precedence in the Mac product line: we’ve had MacBook Pros for several years now with various ways of distinguishing different product iterations (“Late 2008”, “Unibody”, etc.)
Given Apple’s reluctance to publish any of the device’s hardware capabilities, this would seem to make sense.
Except for one small problem. It’s likely that the new iPhone will have a faster processor and more memory. Some applications will be written to take specific advantage of these improvements. And that, of course, means that you need a way to let iTunes customers know if those applications are compatible with their device.
I don’t see Apple putting “iPhone 3G (2008)” and “iPhone 3G (2009)” anywhere in the iTunes UI. It’s just too confusing.
What about having artificial product designations like they did with PowerPC desktop Macs: “G3”, “G4” and “G5.”
The problem here is that 3G refers to a network service, not a product generation. If this naming convention is used, customers are bound to wonder if a “4G” product works on their 3G network.
So maybe they do something like we’ve seen with the iPod product line. Using terms like “Classic”, “mini”, “nano” and “shuffle” to differentiate the products.
The problem here, of course, is that there’s only one product on sale. Unless Apple plans to keep the current product on sale (at a reduced price,) this just doesn’t make sense.
I’m not going to make any predictions on the device’s name, but I will be paying close attention. The ultimate choice is likely to offer some subtle clues regarding Apple’s plans to evolve this product in future revisions.