Swift Regex Deep Dive
iOS MacOur introductory guide to Swift Regex. Learn regular expressions in Swift including RegexBuilder examples and strongly-typed captures.
(Disclaimer: These are my (Joe Conway) opinions. Not Aaron Hillegass’ or any of the rest of the Big Nerd Ranch staff.)
It shouldn’t come as a surprise to the programming community that many developers are upset at Apple’s review process for iPhone applications. In fact, typing “rejected” into my Google bar shows “rejected iphone apps” as a suggestion.
When a high-profile iPhone application gets rejected and the story hits the blogs, there is an uproar: “Apple sucks!” “Switch to Droid!” “It’s all about the money for Apple!” This kind of attitude simply makes me laugh. But, the collective conscious that is the internet is right about one thing, it is all about the money. But not just for Apple, for any business.
A business is a group of employees that provides a service or a product. The money earned from the sale of said service or product is used to pay the employees, cover facility costs, electricity bills, health insurance, buy cleaning products for the office, the list goes on. The revenue generated by the service or product must match or exceed the cost to produce. If the revenue falls short of the cost, employees lose their jobs. A person without a job cannot provide for their family. Therefore, profitable businesses are essential to our survival.
What does this have to do with App Store rejections? Everything. Apple is providing a product (the iPhone) and a service (the App Store) to end-users. Their goal is to earn more money than it costs to create their products and services. To do this, they must survive in a highly competitive market that is growing at an amazing rate. How do you survive in a market like that? By differienating yourself from the competition.
Apple differientiates themselves from competitors by having a consistent and reliable experience. This is why the iPhone is successful. The misunderstanding is who that consistent and reliable experience is for. It is not for developers, it is for consumers. What the nay-saying high-profile developer folk in Silicon Valley have forgotten is that there is a world that exists outside of Northern California. This world is filled with people who don’t understand technology, but still use it everyday. The majority of iPhone users are part of this world – they expect things to “just work.”
The iPhone review process makes sure that these users are satisfied with their product. Now, Facebook developer Joe Hewitt argues that “we have our own product managers and quality assurance testers, and we are liable to our users.” What Mr. Hewitt fails to realize is that he is working for a half-a-billion-dollar corporation with the resources to create high quality applications and test them thoroughly. (Side note: In case you haven’t seen the Facebook iPhone App, do yourself a favor and download it.)
Most iPhone developers are not this well-financed or experienced. When an inexperienced developer writes an application, not only is the application more prone to crashing or not working as intended, the inexperienced developer doesn’t know how to test for these problems properly. If Apple let every application in to the App Store as-is, I would wager that an incredible amount of applications would crash, freeze or generally give the user a bad experience.
The majority of the blame for a poor user experience would fall on Apple. And this is what angry developers are failing to realize: the typical user of an iPhone does not differentiate between Apple and the companies that write software for the iPhone. If a user purchases applications, and the applications crash or don’t work, they are going to be upset at the iPhone, not at the companies or individuals that wrote the applications.
Consider what might happen if Apple allowed Flash web apps to be executed in Mobile Safari. We all know Flash is slow and it crashes Desktop Safari like clockwork. If Flash web apps were allowed on Mobile Safari, Mobile Safari would be slow and it would crash. The end user would not say, “I’m never going to that website again!” They would go to their blog and write, “I like my iPhone, but the web browser is really unstable. I bought this phone to browse the web. I’m switching to (insert next smartphone here).” This would be bad for Apple.
As an iPhone developer, what is bad for Apple and its iPhone is bad for you. If lots of applications typically crashed or did not work, the end user would suffer. If the end user suffers, the iPhone sells less units. If the iPhone sells less units, you, as a developer, make less money because your available market is smaller. The review process is making you money and helping you to be a better programmer. These are good things. (And, without the review process, there would also be even more crap on the App Store.)
Joe Hewitt also argues that “any bug that Apple finds after their two week delay would have been found by users on day one, and fixed on day two.” Yes, maybe by a quality development team working on a high-profile application. However, a less experienced developer team (or developer, singular) may not know how to fix that bug. They may not have a website for users to submit that bug. They may not even know that bug exists because their small userbase has yet to encounter it. It is not in the best interest of iPhone users, iPhone developers or Apple to have unstable applications on the App Store.
Besides all of this, there is still the issue of security. One may argue that the world wide web doesn’t have a review process and it does just fine. I imagine the guys making millions off security software for Windows OS would agree. The iPhone could be another platform they can sell their software on! Could you imagine having to have Norton Anti-Virus on your iPhone? (You could also argue that sandboxed applications make the iPhone safe. Someone will always find a way to bypass security measures. The review process helps to prevent that.)
So, what is the point? You should concentrate on doing the hard work required to excel. You should read the documentation, learn proper memory management and learn better programming practices that ensure your application is stable. Occasionally, you might get thrown a rejection curveball by Apple. You should work through the problem instead of giving up and threatening to switch platforms.
Our introductory guide to Swift Regex. Learn regular expressions in Swift including RegexBuilder examples and strongly-typed captures.
The Combine framework in Swift is a powerful declarative API for the asynchronous processing of values over time. It takes full advantage of Swift...
SwiftUI has changed a great many things about how developers create applications for iOS, and not just in the way we lay out our...