Hrm. Dan Goodin. I recognize that name. This is the same author who published an article on The Register with the title "Skype bug gives attackers root access to Mac OS X", which was factually incorrect. He corrected the headline after much hoopla, but it strikes me that Mr. Goodin is a professional link-baiter.
The title has it backwards. Isn't WiFi sync a fairly obvious feature that Apple has likely had in the works for quite some time?
Based on what I've read, this sync app was only possible because of some low-level sync frameworks that were already present in iOS. The feature wasn't ready by Apple Standards, but Apple didn't want a poor implementation of what should be a system-level feature in the wild. One could argue that the rejection of his app was an act of protecting the user experience. This is something Apple does regularly. If you don't want the protection, you should head over to another platform.
Acting shocked at any of these facts just shows that you haven't been paying attention.
I had a feeling this would get voted down on the basis of it being ad hominem, but in the context of journalism, an author's history of editorial bias is important.
If there's some other reason you think my comment should be voted down, I'm open to hearing it. I enjoy hearing contrary opinions.
When I see "ad hominem" hauled out on HN, I always think of the following from Daniel Davies: "There is much made by people who long for the days of their fourth form debating society about the fallacy of "argumentum ad hominem". There is, as I have mentioned in the past, no fancy Latin term for the fallacy of "giving known liars the benefit of the doubt", but it is in my view a much greater source of avoidable error in the world."
If you want to look at it as a dichotomy, sure, but can't we agree that there's a continuum here? Syncing is certainly a "core" feature. Can anyone be surprised when Apple protects this as something they want to implement?
I think that as an app developer, you have to consider this continuum when you set out to develop an app. Many "utility" apps would be considered closer to the core. Apps like a medical x-ray viewer are further from the core. That's not to say you shouldn't develop a to-do app, but you should A) plan your product ramp in a way that you recover your investment quickly, and B) not be surprised when Apple announces a simple, integrated to-do solution.
One could carry the same analogy to level apps, compass apps, music streaming apps (particularly given the iPod and iCloud), etc.
More relevant to this case, is that Apple rejected an app that (based on the evidence presented) met every knowable requirement for being included in the app store and which had a high probability of generating substantial revenue. Then Apple appropriated the name and icon.
All this makes it hard to consider Apple's actions in this matter to be ethical in any meaningful sense of the term.
The icon was a mix of the Mac's wifi and sync icons. For all we know Apple didn't want their icons used by someone else, that's a legit reason that's been used elsewhere. Also judging by the comments on the TUAW post of this topic, the app was low quality, and the support was even worse. Apple don't like that, rightly.
At the time it was submitted, Apple was not purging "low quality" apps - and as the noted in the Register story, Apple thought enough of its implementation to call the developer and request his CV. This would be more consistent with Apple's engineers being impressed by the implementation rather than it would be consistent with its poor quality being obvious.
Furthermore, given your premise that Apple had something in the works but could not create an implementation which was good enough, it is clearly plausible that Apple's technical review of the app provided a roadmap for improving their implementation to the point where it was good enough.
Finally, it is highly unlikely for poor support to have been a reason for rejecting the application because it can rarely if ever be determined for new apps. The infringing icon argument is not backed up by the fact that Apple did not mention it in their rejection and has not taken legal action in the year it has been in use for the jailbroken versions.
I will be the first to recognize that the plausibility of one line of speculation regarding the course of Apple's actions is no more evidence of an actual state of affairs than the plausibility of other lines of speculation within the discussion are evidence that those events indeed occurred.
> One could carry the same analogy to level apps, compass apps, music streaming apps (particularly given the iPod and iCloud), etc
Yes, because it is a continuum, the argument extends to every type of application, including the outliers I mentioned in my own example. The important point is that some are farther from "core" functionality than others. The closer you move to the core, the more risk you assume.
In my view, a music streaming app on iOS faces a lot of risk. It's Apple's platform. They don't enjoy a monopoly, so they should be free to set the rules of entry. I've strongly disagreed with their policies in the past [1], but my views don't change the facts. Apple's platform, Apple's rules.
This WiFi sync app is particularly high risk, because it's "plumbing". Syncing is a low-level function that reasonable person would expect to be provided by a system service. Apple recognizes that this is the reasonable view and denied the original app for their own reasons. Many of which we cannot know, but we can reason. Being such a "low-level" service, Apple wants to preserve the user experience. This is very typical Apple behavior. I'm not surprised at all that they would deny the app.
The "ethical" question is a much more interesting one. It raises the question, "What are the boundaries of governing your own platform when users have the ability to leave at any time?" I think Apple bumps up against these boundaries all the time. They have a pretty long history of pushing the limits with their T&Cs, then easing back. Is that ethical? I'm not sure.
Its obvious that Apple may want many useful apps on their platform. For many other categories, this hasn't stood in the way of approving an app that conforms to standards.
The factor here is (obviously) that Apple is quashing competition. Working in a walled garden, this is a fact of life. But its frustrating each time it happens.
So to get this straight: the guy who took Apple's icon for syncing and added a wifi symbol thinks Apple ripped him off taking their icon for syncing and adding a wifi symbol? Who'd a thunk.
Mhm. And the fact that he produced the first public implementation of this means that Apple isn't allowed to implement their own version — never mind the fact that such a feature requires lower level control than the App Store guidelines allows for its apps (meaning it's exactly the kind of feature that Apple should be implementing themselves, not App Store developers).
I think that's the main point is that he created an app that was probably declined because it used private APIs (or required root access?).
Also: he produced the first public implementation of what? A wireless syncing software? iSync on OSX came a while before that and I'm sure there have been quite a few before that.
Mhm, so I don't understand why he expected anything different or why people are so outraged it was rejected — that's one of the major benefits of the App Store: sandboxing and access restrictions of apps.
Yeah, as far as I know it was the first publicly-released wireless syncing software designed to let you sync iTunes and iOS.
Only problem is, that's about as generic an icon as you could get by mixing Apple's default iOS icon style with a standard WiFi and Sync icon. Not that unique...
I'm pretty sure that wasn't the "standard" WiFi icon until it showed up in OS X. I think the original "standard" WiFi icon was either this one or the one that looks like a person with radio waves coming out of their head: http://en.wikipedia.org/wiki/File:Wifi_logo.jpg
There was no international standard wireless Internet logo for a long, long time. There still may not be. But this one is indeed Apple’s standard AirPort icon (they dropped one ring going OS X → iOS due to size contraints).
I dunno, the headline is "Apple copies rejected app" not "Apple copies rejected app icon".
Seems to me that people either don't know how the App Store and its requirements work, or they're just want to be outraged at Apple.
Edit: It seems to me that even people commenting here in HN don't realise that the App Store guidelines don't allow for an app to take this kind of access.
The icons are similar (despite how shitty an icon it is), but it won't actually be used anywhere other than apple.com/iOS5 as far as I know; for example it's not even in the Settings app on iOS 5.
Plus people are forgetting that this icon is just what Apple have used for years as their WiFi/AirPort.
If anything, the developer copied — or at the very least, took a lot of inspiration from — Apple's icons for his app's icon.
Oh yeah, I should probably be clear that I personally don't think the icon is a big deal, for the reasons you stated.
I actually don't think anything about it is a big deal. Someone made an app that should have been an OS feature, Apple rejected it for using undocumented APIs, Apple builds the thing that should have been an OS feature, and Apple haters use this sequence of events as evidence that Apple is Evil.
It's basically the same thing as when people enabled multitasking on jailbroken iPhones and then Apple implemented it. Did they "steal" the idea of multitasking?
Copied from another HN comment, but if this is true it'd explain why there's so much furor about it on the boards:
> yardie 36 minutes ago | link
> From what I remember it used the published APIs which Apple then unpublished and rejected his app. This is why the story got so much traction in the first place. If it was another developer doing cool things with unpublished APIs it would have been sold through one of the other appstores and that would have been the end of it.
I wish I was surprised, but this seems to happen with a lot of OS-extending apps on the iOS device. I've never heard of a game being banned from the app store, but as soon as it's something that Apple doesn't already have baked into the operating system...
It's been said before and it'll be said again: Playing in Apple's walled garden isn't a safe way to make a living.
I think it's more fair to say that making things that should/could be OS features isn't a safe way to make a living. Or if you do want to risk it, just be aware that you should have a fallback plan.
Just started using OS X heavily at work on a large monitor and started to notice a bit of a window clutter problem. Your app looks like it could be the ticket!
How is a to-do app "should/could be OS features?" Or a camera app that uses the volume button? Or Instapaper?
I don't think there is an obvious way to tell what Apple has in their roadmap. Specially when they publicly downplay the importance of some features only to implement them later. Maybe they should make their roadmap public? :)
In many cases I think it boils down to "we reject your app because not only we have thought about this use case already but we have a solution in the works, and while it's not ready yet it will probably blow anything else you would have thought about because we know the system in and out, so your app would be dead a few months from now anyway. As you're doing an impressive work on it maybe you can join us to contribute on that work we're doing right now, or be patient about it and concentrate on other areas." In other cases it's probably overzealous employees.
I noticed Apple hate was growing in line with their price history [1] and I understand there will always be baseless haters, but it appeared to really blow out of proportion during last week.
It's not only not a good idea to use private APIs, if you do so you've failed. You're a bad developer. It's like writing file handling code that assumes all operations always succeed. There's a reason private APIs are private. They will change. Your app will crash. It's not a matter of if, it's a matter of when.
Yeah, I mean stories like this shouldn't really discourage developers.
Number one: if you are a developer and you don't plan for something like this that's just a lack of awareness on your part.
Which leads to number two: don't depend on a single revenue stream. You're making decent money with your first app? Cool, now pay a couple of interns to handle support requests and start working on the next one.
Does anyone here seriously believe that anyone in the Apple department responsible for Wifi Syncing will have ever seen this app and its icon?
Apple will have been working on Wifi syncing far longer ago than last May. I wouldn't be surprised if they had it working when they first launched the iPhone but held it back for other sensible reasons (not everyone had wifi, power usage, speed, reliability, no delta updates etc).
Like Authors are warned by their lawyers not to read or accept fan fiction, Apple's developers will be kept well away from reviewing of apps.
The concept is an obvious one; one that has had much discussion on the internet and on this site in particular.
The icon is the most obvious and clearest solution you can draw. I spend most of my day drawing icons and if you had asked me to create an icon for this I am 100% certain that I would have put a wifi logo into the middle of a sync logo. It is a completely obvious thing to do looking at the respective shapes and line thicknesses.
Easily the greatest bullshit i've ever read. This cydia tool was just a hack that activated functions already in place in iTunes and iOS. Just have a look at the 1st gen Apple TV wich had wireless syncing to iTunes since 2006.
I guess they considered it to slow and unreliable in the past to activate it for the iPhone, maybe the iCloud concept, faster processors and wireless networks led to their decision activate it in iOS5.
Seriously. It was always obvious Apple would do this eventually. The kid's app wasn't a novel idea, nor did it have a novel name or icon, it just did something everyone and their mom knew Apple would implement eventually, but just hadn't yet. This app was a hacked stop-over gap to put in place obvious tech. This article is really over the top.
Ludicrous link bait headline and tabloid trash article from The Register.
Apple didn't copy the app, it sound like they were maintaining control of their interests; no one should be surprised by that given Apple's track record.
That's not to say Apple haven't copied others apps, they've positively trampled on a slew of third party apps with enhancements in Lion and IOS 5, but that's all part of the game at this point.
I tried this app in the past. It was very....slow.
Which is why I think Apple rejected it. Their syncing protocol, even over USB, was painfully slow. Over wifi it was dreadful. Apple has a, "do it right or don't do it at all", philosophy.
They seemed to have fixed USB syncing in 4.3 because it takes me less time than before. I'm fairly confident that if he submitted his app after 4.3 was released it probably would have passed, but now that iOS 5 is on the horizon and contains the same functionality it has made his app irrelevant.
From what I remember it used the published APIs which Apple then unpublished and rejected his app. This is why the story got so much traction in the first place. If it was another developer doing cool things with unpublished APIs it would have been sold through one of the other appstores and that would have been the end of it.
It was rejected because Apple changed the rules mid-game
People have been asking for wireless sync for the last decade. Does nobody remember the immortal “No wireless. Less space than a nomad. Lame.”?
That was written in 2001 about the first iPod. (The actual introduction of wireless sync nearly a decade later has been pretty anticlimactic. Apple took so long that no one is anymore very impressed or surprised. I think that it was about 2006 when everyone started believing that wireless sync would be the next big thing for iPods but then came the iPhone.)
This seems silly to me. Apple knows its own product roadmap, so why wouldnt they reject an app that implements a half-baked version of a product line they're releasing themselves?
As a purchaser of Wi-Fi Sync, fuck him. He's an extremely unprofessional developer who provides terrible customer service. Don't buy his app, even at $2.99.
He dropped off the map after promising a Windows beta for WiFi Sync 2, he won't refund purchases for any reason, and he used misleading language that he refuses to own up to when promising sync over 3G.
Apple's implementation will be way better anyways. It's already much faster and it syncs in the background over USB.
Apple is setting themselves up for a Microsoft style lawsuit in the future. Everyone here seems very defensive of apple, and while I think a review policy does help a lot at keeping bad apps out, a move like this could easily be brought to court with a huge settlement having to come from apple. Actually trying to hire the guy could look pretty bad on them as it could be construed as trying to avoid a possible suit.
I'm not saying Apple didn't blatantly rip off this guy's work. But. I'm having a hard time believing someone at Apple saw this submitted to the App Store in May and rushed to get it into the iOS 5 spec a month (or less) later. More likely the app was rejected because the feature was already planned. The rejection response was a cover lie.
In cases like this, do developers have any legal grounds to sue? Would the developer had to have patented some of the technology to gain a legal basis for a suit? If Apple can claim it was a clean-room implementation copying the same functionality, I assume he's just out of luck?
There is nothing like free contract work. This is no different than the way Microsoft treated developers before the anti-trust hammer was brought down upon them.
The title has it backwards. Isn't WiFi sync a fairly obvious feature that Apple has likely had in the works for quite some time?
Based on what I've read, this sync app was only possible because of some low-level sync frameworks that were already present in iOS. The feature wasn't ready by Apple Standards, but Apple didn't want a poor implementation of what should be a system-level feature in the wild. One could argue that the rejection of his app was an act of protecting the user experience. This is something Apple does regularly. If you don't want the protection, you should head over to another platform.
Acting shocked at any of these facts just shows that you haven't been paying attention.