11–20 of 53 posts
Man, this is depressing. As are Apple's terms for the iPhone/iPad store. I'd advise anyone who wants to develop for the iPhone/iPad to stop dealing with iTunes, distribute their work themselves (free and open source) and invite people to jailbreak their products in order to install it.
On top of this, the complaint that Apple do not respond doesn't ring true with me. In my experience, at the very least in the past 6 months Apple have become very prompt in responding, especially to rejection issues, and have provided a contact phone number to further expedite the process.
To me this looks like some guy venting his frustration that Apple are calling his bluffs and is a good excuse for people to gratuitously bag on Apple.
How could he not know that this is what is going to happen when you develop for the Apple store? I mean the first few times, one could understand it - we assume others are reasonable - but this is story number, what 30?
That really sucks, but it is the risk you take when you allow someone else a say in the operation of your business. If you want to have a solid income stream you'd do well to stay miles away from walled gardens where some flunky behind a desk can destroy your business with a click of their mouse.
Indeed. Port it to Android and make a bunch of money there. Or in Nokia's OVI store.
Earlier quoted context omitted.
Indeed. Port it to Android and make a bunch of money there. Or in Nokia's OVI store.
Not to mention that it will actually work better on Android with the ability to run in the background...
There's no way in hell I'd develop anything for iOS while the only way to distribute is via the app store.
I have some serious cognitive dissonance going on though; I have an iPad, and it's great. I'm glad people do run the app store gauntlet so I have nice apps to play with.
Did anyone honestly believe that use of the VoIP in background API was going to be allowed for non-VoIP stuff, though? Having said that, the rest of the story seems conflicting and with confusing back-and-forth.
Did anyone honestly believe that use of the VoIP in background API was going to be allowed for non-VoIP stuff, though? Having said that, the rest of the story seems conflicting and with confusing back-and-forth.
The NPR application appears to be using it to stream audio which is not strictly VOIP.
And this comment: "It’s just not possible to tell them to hold the chatline, send a Push Message, and resend the text to the app when it comes online…"? That's arguably less of a limit, and more of a potential opportunity. Why not create the servers necessary to do that; to allow off-line IRC, and deliver via push? There are folks already using a similar scheme - bouncers - to do that with existing IRC clients and servers, after all. Package that and sell it, and (if your end-user agreements are clear about the potential for dual-use of the servers) package and sell the feed, too.