It seems like every other week I'm reading a blog post from a person who went to a tech conference, or a meetup, or heard a talk, and was rightly offended that someone made a tactless joke about women, either about women in general or about specific women. It is disheartening to hear that any group would be made to feel less worthy of respect in our circle, especially at a time when our industry is undergoing one of the most massive and impactful revolutions in decades, and at a time when we need new blood the most. Every person in our industry should be fighting for inclusivity and should welcome new members with open arms and helpful tutorials. Why there aren't more people pushing for this, I don't know.
It is equally saddening to hear so many respectable people jump to conclusions about what your actual motives might be when trying to have an adult discussion about this sensitive subject. I'll make no qualms about it; I'm a born-middle-class white guy, so right off the top, there will be people who will read this under the pretext that I'm either a misogynist or that I'm some kind of "Internet white knight". As a middle-class white guy, my exposure to injustice and inequality has been limited. I cannot possibly know how it feels to hear words thrown around that minimize the role of women in tech. But I also have rarely been a presenter; who am I to say that I know what Noah Kagan's motives were when he put "faceless bitch" on a slide at a recent conference? He could've been trying to lighten the mood, he could have a vendetta against women in tech. I don't know.
I'm inclined to believe that incidents like this, such as where women are mocked by a presenter, are isolated events perpetuated by a non-representative group of a few people. When I go to conferences, I keep an active ear open for slurs against women, and have yet to hear any. But what's fascinating to me is how women are the group continually called out. A demographic survey created by A List Apart shows that women made up 17.8% of respondents; the same study also showed that Asians, blacks, and Hispanics each represented no more than 6% of the group (which is itself a completely separate topic of inequality that seems to be forgotten in these discussions). Yet women are the demographic so frequently mocked and shamed. It probably boils down to sex and the fact that the people that connect to this industry tend to be more introverted, but I don't know.
The only two things that unite everyone in this industry are that 1) we are all fascinated with high technology, and that 2) we are all humans. As humans we have cognitive biases which prejudice us towards recognizing things the way we'd like them to be. So when we hear that, over the course of several conferences, jokes were made that denigrate women, we're biased to believe that these events are misogynistic in nature, and that repeated incidents show a trend of sexist men trying to keep out women. It's possible that's what's happening; I think the truth is that these people generally are poor communicators and entertainers put into a role of communicating and entertaining, and failing. But I don't know.
I don't know the solutions to the problems we face, but I do know a few things that we all can do better, no matter what subset of demographics you belong to.
- Actively call out unacceptable remarks when they're perpetuated at the expense of any group within our community. Whether that's at the expense of women, men, Android fans, Windows fans, Apple fans, anyone. There is no logical reason for our fledgling industry to show animosity towards any group.
- Fight the groupthink mentality to label anyone who screws up . Nobody is perfect. Everyone makes mistakes. Few people are truly evil and rotten. I'm reminded of this YouTube video on race; watch, but replace "racist" with "sexist". Address what they did, not who they are. Let's address individual problems without calling into question someone's motives, unless someone makes the same mistake over and over without remorse.
- Consider not just on how your message is delivered, but also on how it will be perceived. Your audience will contain not only women, but members of every race, gender, religion, and sexual orientation. Joking at the expense of other groups is juvenile and unbecoming, and will reflect negatively not only on the speaker but on the tech community as a whole.
- Mentor young people who are interested in high technology, and help them learn how to become successful and open-minded. This is something that we should be doing a better job of as an industry as a whole. A teenager who wants to become a software engineer will learn acceptance if they are accepted into a group dominated by grown-ups.
More non-middle-class-white-guy people in our industry will only benefit everyone, from developers to designers to companies to customers. We must be vigilant to keep prejudice out and embrace every single person who wants to contribute to this revolution. But we must be similarly careful not to vilify people for mistakes; hindsight is, after all, 20/20. Of course, maybe I'm wrong. I just don't know.
Be excellent to each other.
Thanks to Faruk Ateş, who has spoken at length on this issue, for his feedback on this post.
iCloud looks like it will be an incredible technology for moving app data between devices. This is inherently a good thing, and it will open avenues for many new types of apps. But, there is a fundamental problem. Right now, the only way to access it is through Objective-C APIs embedded into iOS and Mac OS X. Under the hood, they are obviously talking to the network and doing the business of syncing data, but that networking layer is not exposed or documented, and would have to be reverse-engineered in order to understand and use. So the only way for developers to move their data through this system is through a pre-compiled bundle that gets referenced within an application.
This has a few interesting practical repercussions. If you build an application targeting iCloud, you can only ever put it on two platforms - Mac and iOS. You will never be able to port it to Android, WebOS, Windows Phone, or the web (mobile or desktop). If you sync data through iCloud, And, you will never be able to have a server component that can do things with your data all the time.
Here's some examples of what I'm talking about. In my To Do list app, Todolicious, one thing I would love to be able to do is to push badges to your iPhone and Mac showing the number of To Dos you have left. When you tap a To Do to mark it as done, suddenly all your devices would show the correct number on the icon. With the sync server I was building, this was fairly trivial; wait for the user's list to change, and send a signal to push the count everywhere. But if I back Todolicious with iCloud, I have no way of speaking between my server and iCloud (and I'd still need a server of some kind to send the notifications, after all).
Similarly, if I were to build a web app version of Todolicious (which I was planning on), I could not get access to that data within iCloud at all. I'd have to have either to sync to both iCloud and a custom solution (unwieldy, poor UX and network traffic, and otherwise gross), or not load existing data at all (completely negating the benefit of having such a web app).
So there is a serious ecosystem lock-in problem for apps that wish to target iCloud. All of these problems go away when iCloud is made available as a server-to-server API. A big benefit in the promise of cloud computing includes service interoperability, but right now iCloud is merely a data silo. I have filed this as a bug, rdar://9598555, for a server-to-server API (through which you could build code that speaks to iCloud on your server or on other platforms). I dearly hope Apple addresses it.
Such a server-to-server API would drastically decrease the friction of setting up cloud services to complement an iCloud-backed app, and would lead to better apps and more pleased users.
Osama bin Laden was killed on May 2, 2011 in Pakistan. It marked the end of a manhunt that lasted many years, against a man who funded and conspired to commit several attacks against many countries. bin Laden was the iconic figurehead of Al Qaeda, a brand which inspires fear worldwide. As time led on, it became increasingly less realistic to assume that he would ever face justice. His actions led to two (arguably three) wars conducted by the United States and allies against nations in the Middle East. The world watched Sunday night as President Obama said that his military action succeeded where two the prior presidents had failed at stopping public enemy #1.
I've reflected on this moment a lot over the last couple of days, and have had much difficulty in coming to conclusions on it. Was bin Laden's death justified? I believe it was, given his actions against humanity. Was it morally justifiable to have him assassinated by a Navy SEAL strike team? Probably. Should he have faced jury trial like Saddam Hussain? Ideally, yes, but if the people in the house were firing back at the SEALs, they'd have to defend themselves. Is it equally justifiable to celebrate and revel in the death of bin Laden? I don't think so. Celebration of death, especially one conducted by a government without a trial, is inhuman and barbaric; it inspires hatred of others, which perpetuates the cycle of terrorism.
But my moral decisions are based on my own past. I don't even remember the 1998 US Embassy bombings that bin Laden's al Qaeda conducted (I was only 11 years old then). My conclusions would certainly be different if I lost someone on 9/11, or if I lost family members in Iraq, Afghanistan, or Pakistan. Many others have provided their own insights, such as the fact that Obama did not attempt to bring him to trial. This is too complex an issue affecting too many people personally for it to have a simple right or wrong answer. Some things are neither right nor wrong.
What is right about all of this is that the symbolic head of the hydra of Al Qaeda (and by extension, of fundamentalist Muslim terrorism) has been cut off. To the United States, a symbol that inspires bigotry, hate, xenophobia, and fear of Muslims in the Middle East no longer exists. The face that has risen over the last two years from the ashes of the Iranian election and the uprisings in Egypt, Libya, and others is one of democracy and of youth. While the death of bin Laden will not suddenly cause racists to be less racist, it does have the potential for the US to come to a greater acceptance of those in the Middle East. And that's morally right, it's beautiful, and it's inspiring.
In 2011, with Twitter and Facebook and SMS, we have the ability to blurt out our thoughts with little reflection. This event is not one that has a good or evil label, and one's position should not be a knee-jerk reaction to how you feel in the moment. It is worthy of reflection by everyone, as everyone has invariably been affected by bin Laden's actions in some way. This event has changed the course of some small part of history, and the true effects will be felt many years down the road.
Yesterday Twitter released a new set of guidelines to developers on what to build on their platform. In it, they took a pretty radical view at what is arguably the most popular type of application to build: the "mainstream consumer client". There are easily hundreds, if not thousands, of these apps on the Twitter platform. However, as of yesterday, the official line from Twitter is "don't build these apps any more". This has upset a lot of developers of exactly this type of app (and validates my theory that getting out of writing Streamlines was a good idea!). This announcement will have a chilling effect on innovation, and will permanently and irrevocably destroy any semblance of trust remaining between developers and Twitter.
Looking Back at Third Parties
When Twitter launched in 2006, there were two ways to interact with it. The website (which has now come to be known as #OldTwitter), and SMS. There was no Twitter client, no desktop experience, and no mobile experience. Oh, and they had an API. For the non-programmers in the audience, this API basically consists of a standardized way for apps to contact Twitter and get data in and out. Just about every Twitter app (client or service) you've ever used has used Twitter's API to do its bidding.
People started using Twitter's API to build apps. One of the first and most notable is Twitterrific, which launched around January 2007. As the lead developer, Craig Hockenberry, notes in a blog post made yesterday, Twitterrific was responsible for many innovations like:
- being the first Twitter client for both Mac and iPhone,
- being the first to use the word "tweet" (which is now actually trademarked by Twitter),
- being the first to use a character counter in a tweet composer
In mid-to-late 2008, Loren Brichter of Atebits released Tweetie for iPhone, a pretty universally loved Twitter client (for good reasons). He released version 2.0 in 2009. In that time, he added a ton of innovation, including (among many other things) the now-ubiquitous pull-to-refresh interface concept, which is now pretty much standard on Twitter clients, but also lots of other apps (including Facebook's own).
I've highlighted these two, because I'm a Mac/iPhone guy, but they're hardly alone. Many other Twitter clients that are out now have innovated on the Twitter platform to deliver something greater than the sum of its parts. Millions of people rely on the power and flexibility of TweetDeck to carve out the relevant portions of the social networks it consumes, for example.
All of these innovations were driven by third parties, not by Twitter. In fact, most of these apps pushed Twitter into implementing features which improved the user experience, such as retweets and conversations.
Looking Back at Twitter
Twitter has always been plagued by performance problems. Going back to their launch, they've had constant downtime and slow-to-respond APIs. They've made improvements, but you can ask anyone who uses Twitter that they've still got a long way to go. Instead, they clearly seem focused on shoveling features into their platform. Over 2009, they added several features, including retweets, lists, and geolocation. Each of these were adopted by users quickly, who insisted these features be present in clients. These features were largely added with no real prior announcement or technical information given ahead of time. Most of these features were written once, and then summarily never improved again. Issues still exist with retweets and blocked users, and lists still have the same limitations as when they started.
In 2009, Twitter decided to change up how they authenticate (how a call to the API knows that I'm @SteveStreza and not, say, @WhiteHouse). They switched from basic auth (which sends your account's password to Twitter on every request) to a system called OAuth (which sends a "token", which pairs your account to a specific app, to Twitter on every request). This in itself is a Good Thing, because it makes it harder for a malicious app or person to steal your password, and makes it easier for you to cut off apps you don't trust any longer.
However, Twitter's roll-out of this feature was very botched. Their initial implementation required that all users get sent to a web page, where they entered their password. This design was geared towards web developers, not desktop/mobile developers. As a result of this, implementing OAuth was a terrible user experience for those environments. Due to the poor user experience compared to basic auth, existing clients waited until the very last minute to add OAuth support to their clients, while new apps (which HAD to use OAuth) suffered a competitive disadvantage with a hostile login process. Many clients could not even be written; certain cell phones had such poor web browsers that they couldn't even display the login page necessary. A year later (February 2010), they finally fixed this by introducing XAuth, which allows mobile/desktop developers to present their own UI for asking users for passwords. And in August 2010, the cut the spigot off for basic auth.
But in 2010, everything changed. In April 2010 (not even a year ago!), Twitter acquired Atebits and made the formerly paid app free, under the branding "Twitter for iPhone". They also released Twitter for Android. In September, they launched #NewTwitter, a new version of the Twitter.com website (which had previously had incremental improvements and feature additions). In the beginning of January 2011, they released Twitter for Mac. But the glue that holds this all together: in April 2010, Twitter announced their Promoted Tweets ad platform.
Over the course of one year, where Twitter was encouraging people to develop these kinds of apps, they completely undercut the existing market by putting free apps on a variety of platforms, with no prior announcement about any of this.
Twitter recently introduced the #dickbar (or, officially, the "Quick Bar") to Twitter for iPhone, which forces you to look at whatever trending topic (promoted or not) they'd like. After the backlash, they backpedaled and made the feature, to quote a friend, "less annoying" (it's still a user experience nightmare, but now it's somewhat less so!). Then, a couple days later as users abandon the official app for third-party clients, Twitter releases a statement "discouraging" developers from writing their own apps.
Instead of building the "mainstream consumer client", Twitter says developers should focus on other kinds of services that interact with the Twitter API. Their recommendations include things like "brand insights" tools and "social CRM" apps; the kind of stuff that makes self-described social media gurus cackle but makes actual engineers vomit. They say to build enterprise tools, when they are already building enterprise tools. Their messages and their actions are completely out of sync.
Twitter's intentions have always been packing more functionality into their platform, and informing developers about it as late as possible. As Wayne Gretzky said, "you skate for where the puck is going to be, not where the puck has been". Twitter's made it impossible for developers to have any insight on where they should aim. They provide conflicting messages about their intentions. But most of all, they introduce a level of uncertainty about what it is they're building. Uncertainty kills innovation; if someone doesn't know what the rules are going to change to tomorrow, they won't invest time and money in building something today.
What I Think Twitter Should Do
In-your-face forced promotion and shutting out 3rd-party players is endemic when you take money from advertisers, not users. But many of these users (myself included) are intrinsically tied to the real time social network, and would gladly pay in a heartbeat for value added to the service, as opposed to degraded user experience. Certainly not all, but a significant portion.
Consider the model recently adopted by Reddit, a system called Reddit Gold, where users who pay for the service get perks like extra features and access to early features. On top of that, the service is now answerable to the users who pay the bills, not the advertisers.
To do some calculations, Twitter now has over 253 million unique users per month visiting their site. If 1% of those users were willing to pay $5/mo for the service without ads or promoted tweets, they're looking at a revenue of $151 million dollars per year based on the users they already have who want to pay for this. This is over 3x what they earned in 2010 on ads. These users are the ones who will be deriving the most value from Twitter the service, and will be the least likely to be effected by in-app advertising. They can keep Promoted Tweets and Trends on for those who don't pay. iPhone app developers use this technique all the time; the app is free with ads, or spend a few bucks to remove the ads. These numbers may be higher than reality, but there is a lot of opportunity for Twitter to bake value in at the service.
Additionally, Twitter should focus more on improving the core infrastructure of their service. Their constant downtime is pretty hard to accept four and a half years later. Removing some of the limitations (like the 20 lists or the ability to only access your most recent 3,200 tweets) would be welcome as well; the black box of data that Twitter has stored is massive, and users want the ability to be able to access their own data (hence apps like TweetLibrary which fill that void by maintaining their own database). When Twitter has actually built up their service to the point where it is reliable and not so terribly opaque, they will have a more convincing argument that they're prepared to handle a unified user experience.
However, it may be too late. Twitter has broken trust with their developers far too many times; the developers who helped build Twitter's platform from a micro-blogging service to a cultural phenomenon. Whether anyone will innovate on the Twitter platform any more is yet to be seen, but I doubt it.
I think I'm pissed off at Twitter's announcement today because the wording makes me feel like I'm be lied to and taken for a fool.
Two years ago, I began working on a new Twitter client for iPhone, named Streamlines. I hinted at it about a year ago, and has been a driving force in my development of MGTwitterEngine and a ton of open source projects. I've come to the conclusion that I won't have time to finish and release it, as there's still probably another 6 months of development needed to really ship it, and hostility from Twitter and from users of other Twitter clients make effort into building one unsustainable. However, I think there are UI concepts in there which are totally unique and have never been seen before, so I'd like to share them with you before this project is lost to the annals of dead projects.
Here's a video walking through some of the main UI concepts found in Streamlines.
Streamlines is a social networking client that is designed to show you what you want to see, and hide what you don't care about. To do this, it avoids using tab bars and navigation stacks, and instead uses a card interface with a horizontal swipe, similar to the iPhone's Weather app or WebOS' multitasking UI. You pick which timelines you want to see.
On top of that, you can merge multiple timelines together, across all types of timelines, accounts, and services. For example, if you use Lists on Twitter and Facebook to organize, say, your family members, you can create one contiguous timeline which combines both those lists and shows you what your family members are doing, regardless of where they posted it to. Or, you can combine your Twitter followers, mentions, and direct messages together, similar to how Twitterrific works. This saves you time, as it lets you create your own timelines which show you new perspectives on your social networks that you simply can't get with most Twitter clients.
Streamlines tries to make sure you always are looking at the best data, so for every tweet you see on screen, it will update the relative date in real time. So if a tweet is 6 seconds old, it'll update live to say "6s", "7s", "8s", etc. The time is always up to date, so you know how long ago someone actually posted something. Streamlines accounts for API rate limiting, using some advanced heuristics to schedule API requests so that you never run out. This was more a problem two years ago, when you had 30 API requests per hour shared across all your Twitter clients, but still handy. And it handles incoming and outgoing attachments, so if you or someone else embeds content from another site, Streamlines will replace the URL inline with a preview of the image or video.
Under the Hood
Streamlines is backed by two frameworks I wrote, BirdNest and BirdNestUI. They're frameworks because, well, I actually have about 8 apps which use the same Twitter source code, spanning iPhone, iPad, and Mac. This framework tries to encapsulate a lot of functionality - it includes multiple accounts (with credentials stored in the Keychain) spanning multiple services (Twitter and Facebook, with plans to expand into other timeline services like Google Buzz, Foursquare/Gowalla, Yelp, etc.), networking, persistent data, and lots more. It's powered with Core Data and has about 12 open source projects which make up various pieces. The UI framework contains views for showing and creating accounts and timelines, creating tweets or wall posts, and showing timelines in tables (and there's a corresponding UI framework for Mac).
Why Won't It Ship?
There are many reasons. First and foremost, it's at least 6 months out from being released, and that's optimistic. There are lots of bugs, crashes, and UI problems alone, not to mention whole views just not having been built yet. So there's a huge body of work still to be done. I haven't had much opportunity to work on it recently, and there's not much to suggest I'll have more soon.
On top of that, building a Twitter client has become far less appealing than it was two years ago. In those two years, Twitter has drastically increased their feature set to include a TON of things, including geolocation, native retweets, and lists to name a few. The only way to remain competitive is to iterate extremely fast to include every new feature, whenever Twitter announces them. At the same time, Twitter has made several very hostile moves to make it even less appealing to develop on their platform; the most egregious of which was the acquisition of Atebits and their Twitter client Tweetie. There's now such tremendous market saturation for Twitter clients, especially on iPhone. Releasing a new Twitter app now is difficult, as nobody really pays attention to new Twitter clients any more.
Competing with Twitter's free app is hard enough. Even if I could get it to market, there are tons of users who will demand that every feature Twitter offers be crammed into every new release. And everybody's list of must-haves is different; some people will only care about lists, and will rail on you if they can't edit lists. Some will only care about the geolocation feature and if you can put that on a map. Some will only care about native retweets and seeing a list of people who retweeted. Every one of those features, to these users, is a line item on a checklist that needs to exist. To a developer, every one of those features can take weeks or even months to build properly. But every one has to be in there. Oh, and all of those features need to coexist, cleanly, on a small screen, with a fantastic user interface. It is an insanely complex problem to solve.
All of which needs to be built for an app that will not receive much attention, that will be crowded out of the market and will need to be priced cheaply to compensate, and that will be overshadowed by Twitter's own app anyway. There just simply isn't much reason to build a Twitter client anymore. I would much rather spend my time building an app that users will judge for its own merits, not for its completeness in binding to another service.
I'm not sure what to do with Streamlines as it is today. I do think there is a market for niche apps which use Twitter, and I still have some intention of bringing those to market. But I can't say when, and if they ever come, they will not be full Twitter clients.
I'm considering open-sourcing the code, but I'm not convinced of its practicality yet. I'm hesitant to think that someone will want to adopt a monolithic framework for building their own Twitter apps. It's possible they do. But the code is not the cleanest, and there are surely lots of bugs.
That being said, if anyone wishes to build an app with a similar interface, they have my full blessing and encouragement to do it without any permission from or attribution to me needed. I'd like to see more variance in Twitter client UI in general, as the tab bar metaphor is pretty worn at this point.
I would love to hear any and all feedback, positive or negative, either by Twitter or by leaving comments on the YouTube video above. Thanks for watching and reading.
I booked my ticket and hotel room for the Rally to Restore Sanity the day it was announced. There were some clues of it happening on Reddit once the DonorsChoose campaign kicked off (where Colbert sent a personal message to Reddit when the donation total blew past $100k in 24 hours), so I was prepared when it was announced. Once it was announced, however, it was pretty obvious that nobody really knew what this rally would actually accomplish. Was it just to talk about how the level of political discourse had gotten completely out of hand? Was it to mock Glenn Beck's 8/28 rally? Was it to drive youth turnout to the 2010 midterm elections? Or was it just an opportunity for fans of The Daily Show to meet up?
The truth is a blend of all of those, with different ratios depending on who you talk to. The event itself was rife with comedy and music. The signs and costumes were hilarious and well executed demonstrations of apathy and discontent with the process. The people themselves were extremely nice and polite. It was positive, not negative. It was nationalist, not political. And even if Stewart started his rally wrap-up speech with a rhetorical question of "what exactly was this?", the message was clear, as it was when the event was announced: "take it down a notch, for America".
Most of all, it was a wonderful vacation away from the political rhetoric that tends to get ratcheted up to its most extreme in the days before an election.
What should not be doubted is the impact of the event. The event planners filed a permit for 60,000 people; they got port-a-potties for 150,000. But every estimate has put the number way higher. MTV, Comedy Central's owner, claimed over 250k. National Park Service reportedly and unofficially estimated over 200k. And CBS/AirPhotosLive estimated 215k (of note, AirPhotosLive did an estimate on Glenn Beck's Restoring Honor rally, and pegged that number at 87k ± 9k). And this does not include the thousands of satellite rallies held across the United States and in countries all over the world, as well as all the people who watched it on Comedy Central, on C-SPAN, or watched a stream online. They were clearly not prepared for the sheer size of the crowd. A number of times during the event, especially during the brief and minor technical difficulties, there was a chant of "Louder! Louder!" that swelled from the back and sides of the crowd. The screens and sound systems were not placed far back for many attendees. Even the Mythbusters' appearance showed that it took over 50 seconds for a wave to make it from the front to the back. This event was monstrous in scale.
Stewart's impassioned speech at the end really hit home for me. Juan Williams is not a racist, Rick Sanchez is not a bigot, Muslims are not terrorists, and conflating these makes it harder to tell who's actually a racist/bigot/terrorist. The economic disaster and our wars have made these difficult times, but not the catastrophic end of days that members of the media so often claim. Liberals, conservatives, Democrats, Republicans, the loudest big government progressives, the most staunch of the Tea Partiers, and everyone in between make compromises every day to make society function properly, except in Washington DC and except in the political media.
The news media has largely failed at covering the event. They were there, sure, but they spent most of their time decrying the rallygoers as hipsters and potheads. They also downplayed the effect of those that went by saying those would be people who were already going to vote. Only a couple analysts seemed to understand that it wasn't about the left vs the right, or about the Tea Party vs Progressives, but that it was about the process vs the wants of the people.
It was sobering and illuminating to learn just how many like minded people are out there. Hopefully the politicians and people in the media get the hint, and dial down some of this rhetoric that only perpetuates the problems instead of working to fix them.
P.S. I wrote and published this on a plane. The future? Still awesome.
JailbreakMe.com is a website that offers visitors the ability to jailbreak their iPhone without a computer-based tether. It does this by exploiting the system-wide ability for applications to read PDF files, where an incorrectly-formatted PDF file can lead a hacker to do anything they want to your system. While this bug CAN be used maliciously to steal all the personal data from your phone, the developers in this instance used it to enable jailbreaking.
Others will tell you why you should or should not jailbreak your iPhone. Others will decry the developers for bringing to light a serious vulnerability in the iPhone OS. In this blog post, I won't do any of that, but will instead point out some things you should and shouldn't do if you decide to jailbreak.
Backup first, and backup the backup
It should go without saying that, before you start mucking around with the internals of the software on your phone, you should back everything up with iTunes. Sync down all the data into iTunes, and explicitly backup by right-clicking the iPhone in the sidebar and choosing "Back Up". Once that is done, you should backup the actual backup files to somewhere safe. This way, if you ever want to go back to a vanilla iPhone, it's fairly straightforward. The files are located in ~/Library/Application Support/MobileSync/Backup.
Understand what you're doing
Jailbreaking lets you run apps on your iPhone that, for a variety of political and technical reasons, you could not run otherwise. Apple has gone to great lengths to prevent you from running unauthorized apps on your iPhone, and for several reasons; the most important is for security. Since jailbreaking is designed to let you run those apps, that means that in order for the jailbreak to work, several of those security measures are simply shut off and disabled. This does not mean that you'll automatically get viruses and have your data stolen, but it does open up more avenues for hackers to gain access to your data. You simply must be more vigilant and attentive about security when your phone is jailbroken.
Only add sources that you trust completely
When you jailbreak, you will notice a new app on your home screen, called "Cydia". You can think of this as the jailbroken App Store for your iPhone. You will be able to use this to install lots of apps; you can also install mods that change app icons and fonts, mods that change how apps behave, and mods that add new features system-wide. One way this differs from Apple's built-in App Store is that third parties can publish their own list of apps and mods at their own whim, and users can add those lists to Cydia. You can find lists of third-party sources available by doing some creative Googling.
Now, since you can add any third-party list you want, and those lists can contain mods which can access all of the data on your iPhone, you need to be extremely mindful of which sources you add. Seemingly innocuous apps, such as simple wallpaper lists, can contain code which subtly and sneakily siphons away your contacts, or worse. Since you don't have Apple vetting apps before they hit your phone, you won't be able to trust that an app isn't malicious if it's from an unknown source.
Only install what you need
Many of the apps and mods you can download through Cydia will not be things that you can technically do on the iPhone using Apple's published APIs. An example of this is the project which allows you to install a Growl-like UI for push notifications; it simply is not possible to do through the App Store. This means that you will have mods injecting code into the memory of other apps (sometimes into EVERY app). The more mods like this you have, the more they will start to clash with each other. This can lead to crashes, drained batteries, hangs, and system slowdown. You should consciously try to minimize the number of mods that you install, to preserve the experience of your iPhone.
Be mindful of OpenSSH
Packages in Cydia often times will require use of other libraries to achieve their goals. These needs are called dependencies in Cydia, and they will be listed when you try and install packages. There are packages which will blindly install a package called OpenSSH, which installs a server on your iPhone that allows you to log in via a Terminal. Now, this package uses a file on the iPhone to determine what the default password is, which happens to be 'alpine'. As you can imagine, many people don't change that password by default, and instead just let the default stick and never change it; this led to disaster last year when someone used the default password to extort lazy iPhone jailbreakers.
If you install this package, the absolute first thing you should do is change the root password.
Be wary of iOS software updates
In all likelihood, your iOS software updates will be far more involved than non-jailbreaking. The hacks used to enable jailbreaking are usually patched in the next update of the OS. This means that, if you want to keep your jailbreak mods, you will need to wait for the iPhone dev community to release an updated jailbreak procedure. Sometimes this takes hours, sometimes this takes weeks. Once the jailbreak is released, updating generally consists of backing up everything, restoring your iPhone to the new OS, re-jailbreaking, and reinstalling all of your jailbreak software. It is a far more involved process, on top of the already involved update process of the iOS. You will likely update the OS far less than you would if you were non-jailbroken.
For those that don't know, I've been employed at Ambrosia Software for almost 2 and a half years. In that time, I've helped our team ship some great products, worked to massively improve the user experience on our web site, and expand our presence in and use of social media. It was a great ride that made me a better software engineer by an order of magnitude, and I am forever grateful for the opportunity.
As of this morning, I have accepted a software engineer position at ngmoco😀. As part of this, I will be ramping down my current work at Ambrosia, prepping for a move to the San Francisco Bay Area over the next month. I will begin at ngmoco😀 in July.
I am extremely excited for this opportunity to contribute to the world of social gaming, and look forward to what the next few years will look like. I wish my colleagues at Ambrosia Software the best of luck in the future.
This is hilariously effective. It scrapes a few online lyrics databases and does some analysis to determine the quality of a rhyme. Be sure to check the bottom of the whitepaper for some sample output. Direct PDF link.
iPhone had the first two store UIs; the iTunes Store for content like music and movies, and the App Store for software. The iPad will add a third, the iBookstore, for buying eBooks. These stores all provide content for users to extend the utility of their device. But each has a pretty different user interaction model for accessing, purchasing, and consuming that content.
- The iTunes Store is a separate app that is completely distinct from the iPod app. When you find something to buy, prompting you for your iTunes account password. It then adds the purchase to the app's Downloads tab. Once you have purchased the content, you must then switch back to the iPod app to listen to or watch it.
- The App Store is a separate app. When you purchase something, it prompts you for your iTunes password, and then exits to the home screen, switching to the screen where the app will live. The state of the download is reflected in the app icon. When the download is complete, you tap the icon on the home screen to use it.
- The iBookstore (the one word is the official name as used by Apple) is not a separate app, but lives within the iBooks app on the iPad. Purchasing content prompts for the iTunes password and downloads in-app, which can be directly accessed after it has finished downloading.
Each type of content follows a different workflow when going from access to purchase to use. If a goal of the iPad's low price is to drive content sales through the three stores, as some speculate is the case, then the purchase model should be as streamlined for the different types of content. Forcing different workflows will only confuse users who can't remember which type of content comes from where.