iPhone SDK Bug Filing
March 11th, 2008The iPhone SDK announcement has come and gone and reality is beginning to set in. The SDK provides opportunity for lots of great new applications on the iPhone. However, there are also a great many restrictions. As Quentin noted, we worry about the potential for innovation to be stifled, due to these restrictions.
In an effort to remedy this and remove some of the limitations, we’ve submitted a number of bug reports to Apple. Some of these are useful specifically for us, while others are beneficial to anyone, but our goal here is the same with all of them - we want to make the iPhone platform as robust and powerful as possible.
A list of our requests for enhancement is below - developers are invited to submit duplicates and Apple engineers can view the full submissions with the links provided.
Allow applications to be installed at the user’s discretion, not Apple’s
This request basically asks for Apple to not be the exclusive provider of applications for the iPhone. Having an App Store is certainly a great new venue for sales, but it should not be the only way to get software on the iPhone. Just as Apple sells music, but also lets you load MP3s ripped from CDs onto your iPod, you should be able to install software from other sources.
This is perhaps the most important issue - if this restriction is lifted, many others become far less important.
Allow applications to run in background on iPhone
The hardware is certainly quite capable of handling this. Indeed, many of Apple’s own applications run in the background, from Mail to SMS to iPod. Not all applications need to do this, but an AIM or IRC client should, as well as anything involving file transfers.
Allow access to root user on iPhone
Perhaps this one sounds outlandish, but the fact of the matter is, you own this device just as you own your Mac. This access should be controlled, just like it is on desktop Macs, by some sort of password or setting. Apps should not be able to get root without permission, but we believe an open platform is best.
A MediaPicker API for accessing the iPod music files is needed
Just as applications can access photos and contacts, we want to access music. This one has a very specific use in mind for us, Airfoil for the iPhone needs to be able to access music on the device. However, many other applications could make use of this as well.
Add option to allow iPhone applications to access entire filesystem
To do interesting things, some applications need access to data beyond what they create. Image and Contact Picker are a start, but what happens when a suite of applications is made by one company? How will one app edit another app’s data? This is an extension of needing a MediaPicker, but it would be much broader and more powerful.
Allow iPhone applications to access the host computer when docking
There’s a lot of valuable functionality to be had in an application which acts as an extension of a Mac or PC program. Imagine automatically synchronized to-do lists, blogging/photo apps, instant messaging logs, and much more. Without being able to access the host computer, these are forced to either go through local wifi or through some sort of centralized server, both of which offer a poorer experience.
Currently, only Apple can do this - with iCal, Contacts, and Safari bookmarks. Other apps can certainly benefit from this as well.
Permit Voice over IP on the cellular network
This limitation is arbitrary and is obviously motivated to placate AT&T. VoIP has no more impact, and arguably less impact, on the cell network than a regular voice call. Data should not be segregated. It’s all bits, and if my bits are coming out of a handset speaker in Beijing, Apple shouldn’t know or care.
We don’t expect anything will change here, but it certainly should. The principle here is the same as network neutrality for the Internet.
Bug ID #5788806
Allow iPhone applications to access the docking port
The ability to communicate with peripherals would enormously expand the potential for third-party applications. For example, an iPhone could be plugged directly into a camera to tag and upload photos to a web site from the field. A plug-in GPS unit could be used for car navigation or trip logging. A microphone could transform the iPod Touch into a mobile podcasting device. And there are many more opportunities for innovation which would be created by allowing iPhone software to talk to such external devices.
If you have an ADC account, you can submit your own bugs at http://bugreport.apple.com. Plenty of things are still in flux, and with input from users and developers, Apple may just see what a powerful platform the iPhone can be.
Update (3/11/08 10:30 PM): There seems to be a bit of confusion regarding bug filing and the use of bugreport.apple.com to provide feedback. Three things to know:
1) This is the method for providing feedback to Apple. Don’t let the name fool you - there’s an “Enhancement” option which is what we’ve chosen for these.
2) It was expressly suggested that we provide feedback in this manner by multiple Apple engineers, including those who’ve worked on the iPhone team.
3) It was expressly requested by Steve Jobs himself that we provide feedback on the SDK.
We’re not spamming Apple with this, we’re providing Requests for Enhancement, in the exact manner their system is designed to be used.
March 11th, 2008 at 1:02 pm
This is a good way to handle the situation. There’s some here that I will file as well, and some that I won’t. If everyone were to file what’s important to them, Apple would have a better idea of which limitations absolutely positively MUST go.
March 11th, 2008 at 1:30 pm
Hi
I downloaded the SDK but don’t have an iPhone to try this out:
Anyone can download the SDK, just need to register with Apple, it’s free.
Anyone with the SDK can install an app on a connected iPhone, obviously to debug it.
Does that app stay there once the iPhone is unplugged? If so, it’s a work around for the first issue… (although it does require you to distribute apps as source I suppose)
Also: Apple won’t allow apps that do sim-unlocking or do voip over the cell network. Is that an SDK limitation or an AppStore limitation? If it’s AppStore only, the same method as above could be used to work around it.
Mike
March 11th, 2008 at 1:47 pm
Mike: Alas, if only this were true. But just having the SDK is not sufficient to be able to load apps onto an iPhone. You also need to pay your $99 and get your developer certificate. Without this certificate, the SDK can only be used to run applications in the simulator. There could be some small underground trade amongst people who’ve paid the fee to join the program (and been approved), but this is a poor substitute at best.
March 11th, 2008 at 2:04 pm
Worse, to enable loading devices you’ll need a profile that can restrict what the phone can do (make/place calls, access the ATT network at all presumably) that you get from Apple. We’ll see once the program starts accepting people how restrictive those profiles really are.
March 11th, 2008 at 2:16 pm
You do realize that a road-map and an SDK preview do not mean the final product? I see your point and I kinda support the cause, but flooding Apple with bug-reports it bit extreme wouldn’t you agree?
This seems akin to spamming.
March 11th, 2008 at 2:16 pm
I’m really disappointed to hear there isn’t a picker for music files and submitted a dupe.
March 11th, 2008 at 2:27 pm
Yuli,
The SDK is not a beta. Regardless, even betas are submitted to the public for feedback which includes bug reports and feature requests.
Further, I can’t think of a better way to voice and opinion and shape the development of the iPhone SDK platform than what RA is doing.
Lastly, it is not in the least like spamming which by defintion is, “he abuse of electronic messaging systems to indiscriminately send unsolicited bulk messages, ” according to Wikipedia.
March 11th, 2008 at 2:52 pm
Yuli: This is precisely what Apple -asked- us to do, they wanted us to provide feedback. Is this the final product? No, there will be changes. But we want Apple to know what changes we believe are needed. Submitting bug reports does just that - this isn’t spamming, it’s providing feedback.
March 11th, 2008 at 4:15 pm
Chris: The SDK -is- in beta. Check its readme file.
March 11th, 2008 at 4:16 pm
your argument for user installations:
“On Mac OS X, users are free to install any software they like, and it works quite well”
…until it doesn’t, and then Apple gets the blame. I’ve seen this over and over and over and…
So until you figure out a way to correctly assign the blame, I’m in Apple’s camp on this.
March 11th, 2008 at 4:19 pm
Funny thing is I’ve filed quite a few of these independently. And I’d bet a lot of other developers did, too.
The SDK as is provides a good first step, but the potential of the iPhone is much bigger. (Oh, and if you want to add one, it would certainly be nice if iPhone apps could recv/send SMS messages)
March 11th, 2008 at 4:20 pm
I absolutely agree with filing these bug reports. It’s the most direct way for us developers to speak up. I too think the iPhone should be opened up. If I can use sudo/root on my Mac (after all, a device I own), there is no reason why I should not be able to do so on my iPhone.
Instead of locking things down, Apple will be surprised how many innovative apps will spring to life once the API is opened up. It can only benefit the iPhone and the entire ecosystem around it.
If you have an ADC and are developing for the iPhone, I certainly recommend to file bug reports for these misfeatures.
March 11th, 2008 at 4:26 pm
While I agree with some of these ideas, this is nothing more than a wish list, not bug reporting. Flooding Apple with these so-called bugs, may detract from actual bugs getting their due attention. There must be a feedback forum for these types of requests?
March 11th, 2008 at 4:28 pm
These are great, thanks for the ideas. I would like to file bugs not against insufficient filesystem and library access, but against the sheer lack of inter-application APIs. Apple should be providing suitable APIs for safe and structured access to the address book, email, iPod library, photo library, and so forth. BlackBerry provides APIs like these for all the standard applications, and allows invoking those other applications to make them do useful stuff. I would love to have the same APIs on the iPhone. If they don’t exist, people are just going to cook up their own unsafe ad hoc hacks to accomplish the same things.
March 11th, 2008 at 4:30 pm
On the VoIP thing, I can’t see how there’s a benefit to anyone but the most shortsighted consumers in enabling this feature. Essentially, your problem is with the spead of wifi access, since the only major difference with cell carriers is coverage.
But with enough really nice wifi-only features for iPhone, suddenly there’s a built-in driver for additional wifi adoption as the platform increases in popularity. Rather than just being a controversial public service, iPhone-based apps and VoIP/presence technologies could be the way municipalities justify their wifi efforts, reduce their costs, etc.
By forcing more advanced/”killer” apps into the Wifi box, you’re not making them useless to the guy on the side of the road in the middle of nowhere… You’re making them infinitely more useful for the rest of us at home, at work, and on the go in the major metros.
Other than that, I think your post has lots of valid issues (if not outright bugs), though I’m not really big on the idea of an iTunes-free distribution system, either. As someone else mentioned, when my phone blows up, I know who I want to but can’t call about it - Apple. Don’t let Steve and Co. muddy the waters any further by playing the Microsoft “blame third party vendors” game.
March 11th, 2008 at 4:39 pm
Michael Tomlin: You ask, “There must be a feedback forum for these types of requests?” The answer to that is yes: the feedback forum is Radar, Apple’s bug reporting application. We are not doing this instead of providing feedback, this is providing feedback. Filing bugs about what we want changed is what multiple Apple employees have told us to do.
March 11th, 2008 at 4:44 pm
I disagree with the idea that iPhone applications should be able to access the entire filesystem, at least to the extent there are no controls. I think applications should be able to allow other applications to access files and so form a community of apps that can work on some specific data, but that’s as far as it should go for now - otherwise you’d get things like CuteKittyRampsThroughFlowers.app that secretly took the whole database from MyBankPasswordStore.app and sent it off to Russia. The sandboxing model is good I think as long as apps in the sandbox can request some wider scope for good reason.
To me it seems to make more sense to have sandboxes totally locked down now, and then figure out slowly in what ways it makes sense to open them. It seems like a workaround for now for the suite idea would be to have each app register a custom URL handler and call a browser with your data… yuck, but it might work.
March 11th, 2008 at 4:49 pm
Having left the Treo camp for an iPhone - and having just spent a weekend getting my wife’s Treo back in shape for her - I’m willing to give Apple some leeway. The Treo is a great phone - until it isn’t anymore - then you have to start trying to figure out which application is causing the problem, be it battery drain, slowdown, freeze, crash, or reboot cycle. I’ve had it happen time and time again.
And that’s what I spent the weekend doing with my wife’s Treo 680. Theoretically, her problems were caused by one of the two programs she added earlier in the week, just before her crashing and reboot cycles started. Just as theoretically, I should have been able to remove those two applications (and their data libraries) from her most recent backup and just the sync process put it all back together. Theoretically. In the end I wiped it all, synced her data, and then laboriously added program after program, entering serial numbers as I went. Oddly enough, when I was done and backed it up the backup looked EXACTLY like the backup that I started with - the one that crashed and burned three times in a row.
No, that experience, and my experience with Windows Mobile makes me think Apple has the right idea. What I want more than a whizz bang phone with dozens of whizz bang 3rd party applications is a stable phone and internet platform.
March 11th, 2008 at 4:50 pm
I think Apple should institute a two-tier app system:
* Apps that are blessed & distributed through Apple
* Independent apps installed at the user’s own risk
When you sync your iPhone, iTunes notifies you, if it sees independent apps, that these apps may cause problems, and offers to uninstall all non-blessed apps. This way, Apple can easily segregate its universe of apps from anything that might cause trouble. The first thing the genius at the Apple store says if someone has a problem is, “Press the button to uninstall all your non-blessed apps.” This way, Apple is off the hook, and we get to have our cool apps without jailbreaking our phones…
March 11th, 2008 at 4:51 pm
To be honest, I can’t really see the point of most of these “bug” reports. The iPhone is not a Mac. I’ll repeat that. The iPhone is NOT a Mac.
Just because it is (largely) based on the same technologies doesn’t mean that it is the same platform, with the same purposes, etc.
Apple are the gatekeepers for the iPhone at the moment. The iPhone is very limited compared to any Mac from the last decade, pretty much. It has a completely different viewport, and it’s processor capabilities just don’t allow for pure multi-tasking. Sure, some things can run in parallel, but not everything. Apple have to control this, otherwise the user experience could be ruined by over zealous, geeky developers who just don’t get it.
What you are describing - what you seem to want - is not what the iPhone is, or what it currently could be. The iPhone is a phone. It is not a “Mac in your pocket”, and never will be. It will only ever be a sub-set of what a “Mac” is.
March 11th, 2008 at 4:54 pm
I agree with some of these ideas, but I also understand Apple’s concerns:
- They do not want to jeopardize their relationship with AT&T by allowing customers access to unlimited calls over VoIP.
- They want to prevent the spread of malware. If users can install any app, and any app can access the filesystem, the host computer, and the cellular network, it wouldn’t take long at all for some seriously damaging malware to appear.
- They don’t want apps to drain the battery. I would like to see *some* applications be able to run in the background (IM clients, and possibly a “friend locator” of some kind), but perhaps they’ve imposed the restriction so that it can be the exception rather than the rule.
March 11th, 2008 at 4:55 pm
Joe: Do you believe the Mac would be better if Apple had to approve every app you installed? Choice is messy, yes, but it also leads to fantastic end-results.
Rice’s Theorem tell us there’s no way they can properly test every app, so the “security” there is illusory.
But ultimately, nearly all of this is solved if Apple simply allows another way onto the phone.
Michael Tomlin: “There must be a feedback forum for these types of requests?” Yes, and it’s precisely the one we used - bugreport.apple.com, and the Enhancement option is what should be used here, and it’s what we’re using.
Deano: How is VoIP over cell short-sighted, exactly? The question is, why is Apple segregating bits? The answer seems to be “To appease AT&T”, and nothing else. If it was an issue with bandwidth, YouTube definitely shouldn’t be capable of working over EDGE.
If you don’t want third party software on your phone that isn’t approved by Apple, that’s OK. But should everyone be held to that same limit?
March 11th, 2008 at 4:58 pm
You forgot:
Allow iPhone applications to access the Bluetooth radio. That way developers can support iSync and file transfers over Bluetooth, or communicate with currently unsupported Bluetooth devices, like external A2DP devices and GPS receivers.
March 11th, 2008 at 5:06 pm
I’m not in favor of all of these, but some are crucial. For example, I don’t think the entire filesystem should be accessible, not without jumping through a lot of hoops, for security reasons; but being able to access the user’s iTunes library is crucial for a lot of apps. (And not just for stealing music. For example, imagine the awesome DJ interface you could build with a multitouch UI to control faders and scratch wheels.)
FYI, the URL scheme for Radar bugs is “rdar:” not “radr:”.
March 11th, 2008 at 5:06 pm
Also keep in mind that the developer program is currently U.S. only, which means no developer outside the U.S. can test an app they’ve built on real hardware, let alone distribute that app.
March 11th, 2008 at 5:09 pm
I agree with some of these and not with others Specifically, I’m fine with the idea that only approved apps can be loaded on my iPhone. I have a jailbroken one now, but I’ve had to restore it a number of time because of buggy behaviour which ceases until I re-jailbreak it.
I think the way to solve the system-wide file access without actually allowing system-wide file access, because again, I prefer to know that what I do in one app stays there, is allow developers to provide their own data manipulation apis. I think this would be fairly simple for both developers and Apple.
March 11th, 2008 at 5:15 pm
Gareth: You’re right that it’s not a pocket Mac, and that’s the whole problem. I want a pocket Mac. The people with jailbroken phones have been enjoying pocket Macs for months, and overall it seems to work out great except for the lack of official blessing.
I want to address the issue of the iPhone’s hardware capabilities, though. You state that the iPhone is very limited to any Mac from the past decade, and that this necessarily limits its ability to multitask or do a lot of other interesting things. You’re not the only person to say this by far. It’s a very popular statement. But it turns out not to be the case.
A decade takes us back to before the original iMac. The original iMac had a 4GB hard drive, 32MB of RAM, no 3D hardware acceleration to speak of, and a 233MHz G3 CPU.
My newly-purchased iPod Touch, basically identical to an iPhone except for the lack of phone-specific hardware, is significantly more powerful in every way. It has twice as much nonvolatile storage, and this storage is much faster. It has four times as much RAM. Its CPU is roughly 2-3 times more powerful. It has pretty good hardware 3D acceleration.
The iPhone and iPod Touch are, hardware wise, the rough equivalent of a midrange iBook with an unusually small screen and no keyboard. Midrange iBooks run the full desktop version of Mac OS X just fine, handle multitasking and arbitrary programs and all the rest without comment. They’re a bit on the pokey side today, but that’s just because we have hardware that’s so much better now.
March 11th, 2008 at 5:20 pm
Waaa waaa waaaa
March 11th, 2008 at 5:34 pm
Your quite right, and if Apple made the switcher back in 1985, surely they must be able to do multitasking on the iPhone.
March 11th, 2008 at 5:35 pm
FYI, for the “Add option to allow iPhone applications to access entire filesystem” issue listed above, there’s an officially support way for apps to access each other’s data. Through the use of URLs, (ie a published API for each app). This just means that each app has to approve another app accessing it’s data, which seems good to me.
March 11th, 2008 at 5:35 pm
As an iPhone user (and sometimes shell and AppleScript scripter), I have to agree with Apple on almost everything you don’t. Desktop computers and their applications can be unstable (even good old Mac OS X — Input Managers?) and vulnerable to viruses, etc., with the iPhone we get a new start and a chance at trying something that might give users (Me!) a better experience.
I for one am willing to give the closed shop a chance. Here are a few specific reactions:
* Allow applications to be installed at the user’s discretion, not Apple’s — I agree that this seems greedy. Applications, it seems, could be signed without being sourced centrally. Probably the main reason (other than the money) is that FairPlay is added to the application, making it a little difficult to copy an application to another phone. Computer Copy Protection Round X (sigh). I’ll give you this one, but it might take time for Apple to change its mind.
* Allow applications to run in background on iPhone — I disagree, again, speaking as a user. If I close my little AIM application, I am done with AIM — there shouldn’t even be an online/offline switch in the UI (again, speaking as a user — why should I have to take the extra step?). Now if I just shut off the display, go ahead and buzz if I get a new message (and if they kill the app when the screen is turned off, that would be annoying). But if you are running in the background and beep at me when a message arrives — how am I supposed to know what caused the beep? Remember, no floating dialog boxes and I don’t want six tiny custom icons on my status bar. I think the no-background rule makes good sense from a UI and general simplicity standpoint, even if the phone is technically capable of such a thing.
* Allow access to root user on iPhone — I can’t see how why that would be even especially useful, considering how iPhone system software upgrades work (overwrites everything but user data). This seems to be a stability over functionality decision, but hopefully the Touch OS will be stable enough for this to be the right choice.
* Add option to allow iPhone applications to access entire filesystem — I know you aren’t asking for what I’m about to say — but I really, really don’t want a Finder or open/save dialogs on the iPhone.
* Allow iPhone applications to access the host computer when docking — I’d say handle this more or less like everything else (Pictures, Video, Music). Allow an application to register with iTunes and allow syncing of data between a desktop-side application and an iPhone-side application. I see the Touch OS as being an experiment in a “Finderless” Mac OS X, and I’d like to see where the experiment takes us, rather than start right away to cruft it up with file system admin details exposed to the user.
And please, no hard feelings — eventually I’m going to absolutely need Audio Hijack Pro, and I’ll be glad you guys have it.
March 11th, 2008 at 5:37 pm
I’ve filed some similar bugs.
I don’t personally agree with VOIP on cellular networks, accessing the _entire_ file system, root users, and a few others.
The one that matters most to me right now is enabling the ability to synchronize with a desktop application via the dock cable and iTunes. Currently, you’d be forced to do so via wifi only, and not everyone has a wifi network.
March 11th, 2008 at 5:40 pm
Ken: Why do people act like the iPhone would be especially prone to malware? Just about every other mobile platform (except for recent versions of Symbian) can run unsigned applications, gives them some kind of network access, and has a synchronization API.
March 11th, 2008 at 5:40 pm
To anyone who hasn’t used Apple’s Bug Reporter: Options have been added to the Product field for both the iPhone and the iPhone SDK.
March 11th, 2008 at 5:43 pm
Submitting a list like this seems like the right way to approach the discussion.
I think Apple are probably playing over-cautious on some aspects, waiting to see what apps get developed with this level of restrictions. If there are problems, it’s a lot harder to remove access once it’s been granted than lift restrictions in the future.
I do think that some e.g. no background tasks are designed to maintain a great cell phone experience. You really, really want a snappy switch to the phone app, and Apple have rigorously tested the impact on their background tasks.
I’d also throw out there that I’m unconvinced that the issue outlined by Bug ID #5788801 is necessarily the right solution. For your outlined scenario, I’d suggest that apps signed by the same certificate should be able to access those areas owned by other apps signed by the same certificate.
March 11th, 2008 at 5:46 pm
Paul - you say “Rice’s Theorem tell us there’s no way they can properly test every app, so the “security” there is illusory.”
But the security is not meant to wholly be in Apple’s testing. It is in other features you want to take away. You want to take away even that thin veneer of QA from a trusted party. You want to remove all limitations to file access. You want apps to be able to gain root access. And you want apps to be able to come from anywhere, with no accountability attached to them with no requirement for app signing.
Does not that sound like an utter security nightmare? As another poster noted, such a platform would be a haven for malware from the word go.
I also do think after further thought, that having apps quit which you switch away from them is actually a pretty interesting, and I think very useful UI element. It keeps users from wasting very limited resources, and essentially forces all applications to endorse an implicit state saving model that I like to see in applications anyway. Probably again apps should be able to request background operation in some way, but I think the ability to do so should be pretty restricted as it leads to developer laziness.
March 11th, 2008 at 5:52 pm
The last thing 98% of users want is some haxie crap getting installed and completely destabilizing their device. People are going to have WAY higher expectations for this newer class of device in terms of stability and consistency. We simply cannot afford a completely unrestricted environment.
March 11th, 2008 at 5:56 pm
Kendall Gelner: Every Mac I’ve ever owned had no Apple QA on third-party apps, no limits on file access, the ability to gain root, with no accountability for apps which could come from anywhere and be loaded by anyone. And yet it has somehow failed to become any sort of security nightmare, much less this haven for malware that everyone seems convinced the iPhone is just inches away from.
March 11th, 2008 at 5:59 pm
I do not see how Apple can be expected to allow voip over the cellular network. This dierectly hurts their partner, AT&T, who is kicking back tons of money to them from the bills paid by iPhone users.
AT&T should not have to allow you the ability to circumvent using your cell plan minutes over their data network. It would be nice, but it would be stupid on the part of AT&T and Apple. There is too much opportunity for lost revenue there. bandwidth isn’t free, and heavy voip traffic would clog the network.
March 11th, 2008 at 6:03 pm
@David Rouse: There are other apps that *need* to be able to work in the background. I’d love to write a podcatcher for the iPhone - and that only works if I can download in the background, and periodically check RSS feeds.
I’m happy if that runs as a ‘nice 20′ process - but I need it to run in the background.
On the other hand, I can understand Apple - a couple of those, and your performance is going to suffer. Thankfully, I don’t have to solve that problem ;)
March 11th, 2008 at 6:04 pm
Mike, you’re wrong. People with “jailbroken” iPhones (god, I hate that term) haven’t had a “pocket Mac” at all. What they have had is a bunch of largely crummy applications for geeks, implemented in an ugly way. Ugly to look at, ugly to use.
The iPhone - like the iPod - is not a geek platform.
Forcing an iPhone to perform the same sort of tasks as a Mac just because it might technically be able to is missing the entire point of the device, and the platform.
That is one of the reasons that Apple took some time over the SDK announcement. They wanted people to get used to the iPhone as a device, multi-touch for input, the screen viewport.
What developers should be thinking of is what can they do with this new platform, within the constraints of what the device is. They should not be thinking about porting any applications to the iPhone just because a bit of fiddling in Xcode means they can.
I don’t want a Mac in my pocket - whether it is as powerful as an original iBook or not - because my Mac is at home, or in my backpack. What I do on my Mac is, well, what I do on my Mac. I am never going to want to edit photos on my iPhone, or even really compose documents, because the viewport is completely inappropriate for those types of activities.
The iPhone already does 90% of what I want it to do. And I expect that is true for most people. Sure, there will be some specific apps and services that people will want / use, but for most people that will be one or two things.
I love what Apple has done, and the way in which they have done it. You only need to see the utter, utter crud that passes for “software” on other mobile platforms to see that Apple as a gatekeeper is a good thing. A very good thing. The iPhone will never do everything that a geek wants it to do - no platform ever will.
It’s not a pocket Mac. It never will be. Because that isn’t the purpose of the device, or of the platform. And developers have to understand that, otherwise the iPhone platform will be a shit storm like Windows Mobile.
Basically, you can’t have it both ways. If it is going to be a high-quality experience, then someone is going to have to judge what makes it, and what doesn’t.
March 11th, 2008 at 6:10 pm
Kendall Gelner said:
“Does not that sound like an utter security nightmare? As another poster noted, such a platform would be a haven for malware from the word go.”
Mac OS X allows full filesystem access to apps that request it. Mac OS X allows apps to come from anywhere with no accountability attached to them and no app signing required.
Are you suggesting that Mac OS X is a haven for malware? If not, why would these restrictions be necessary on an iPhone but not a desktop Mac?
March 11th, 2008 at 6:10 pm
Troy: They shouldn’t call it an “Unlimited” data plan then. Just as Comcast shouldn’t be calling their internet service “Unlimited”. I’m glad he made this point just out of the precedent it lays. The Internet should be neutral. Bits are bits. To do anything less will stifle innovation. Asia is already killing us in this respect.
March 11th, 2008 at 6:17 pm
*Especially* since YouTube gets an exception, and it was allowed to work over Edge. Hopefully 3G won’t follow the same non-neutral path.
March 11th, 2008 at 6:20 pm
ZeroConf is a workaround (if not the preferred path) for the bulk of the desktopphone integration
I for one am plotting out phone EC2 integration, too, since persistent network connections are going to be interesting and useful.
I’ve got six ideas on the stove now, so I think Apple hit a grand-slam walkoff home-run with this announcement.
March 11th, 2008 at 6:24 pm
“The people with jailbroken phones have been enjoying pocket Macs for months, and overall it seems to work out great except for the lack of official blessing.”
I’ve been using a jailbroken iPhone for quite awhile now and it is *very far* from being a pocket Mac. There are very, very few applications that offer much utility and, though it’s nice to have a terminal (of sorts) and be able to shh to a remote client, it’s a pretty poor substitute for Terminal.
That said, I do hope that Apple allows the sharing of data stores and opens up the ability to sync data easily. Maybe then we’d get the basic ability to have synchronized notes and to-do’s.
March 11th, 2008 at 6:38 pm
I’m curious, and maybe one of you devs could answer this for me, what is meant by “running” on the iPhone? Does that mean having the application open in front of you and working on it, or having it anywhere in memory (the way an app on the Mac can be open but not active)? I ask because I’m wondering wouldn’t an IM app run the same as the SMS app? I’m only really “running” the SMS application when I’m inside it, reading or composing a message. However, I can still get alerts even though I’m running another application.
As much as I hate to say this, I think we’re lucky we got VOiP in any way at all. I’m curious what will happen if Amazon decides to try and release an Amazon MP3 app, and what Apple will say to convince people that not allowing it is a benefit to them (because I really can’t seem them letting it through).
March 11th, 2008 at 6:41 pm
The trouble with using the bug-reporting system for these kind of issues is that, just as you say, they’ll be read by Apple ENGINEERS. But the bulk of your complaints relate more to business issues rather than technical issues, so what Apple engineers think about them is immaterial.
For example, “Allow applications to be installed at the user’s discretion, not Apple’s” really means “Rogue Amoeba doesn’t want Apple to come between it and its customers.” “Allow applications to run in background on iPhone” really means “Rogue Amoeba wants to have the option of offering chat or IM applications that compete with the big boys.”
And “Permit Voice over IP on the cellular network” really means… well, it means that somebody is living in a fantasy world about the nature of the iPhone. Like all commercial products, its fundamental reason for existence is to make money. Apple did not introduce it as an act of generosity to humankind; the iPhone is intended to make Apple money, both directly and via carrier contracts.
Even if, someday, Apple allows VOIP applications on the iPhone, the decision will not have been made by Apple engineers. It will have been made by businesspeople, with Steve Jobs’s blessing. The number of duplicate bugs complaining about the issue won’t make a difference.
March 11th, 2008 at 6:42 pm
It’s nice that you want a pocket Mac. But Apple’s customers want a cell phone, or an iPod, and they expect those things to be appliances, not computers they have to fuss with. Most of the limits seem entirely appropriate to me, in that context. Maybe they’ll make you your pocket Mac, but this ain’t it.
March 11th, 2008 at 6:45 pm
response to Paul:
No one addresses the blame argument — you have no idea how many users I interact with who get absolutely IRATE at Apple for something that Apple didn’t do, nor had any control over. Look at all the idiots who hacked their phone, making it a brick, and then wanted Apple to fix it!!! But let me get to the bottom line — I’ll make it really easy, so that everyone should be able to get this:
I don’t depend on my Mac to make 911 calls.
March 11th, 2008 at 6:50 pm
All our years developing for Mac have blinded us on the scummy-ness of developers.
The iPhone is entering the mobile industry. An industry plagued with pure crap and money-grabbers. Have you seen those those subscription-based ringtone/java app commercials on TV? “Play tetris on your mobile! That’s right! Tetris on your mobile! SMS GAME6 to 19400″ Behold the mobile industry in all it’s glory. Jamster spawned from the gullible suckers of the mobile industry.
Those scummy, gnawing, rat-like developers (imagine Jack Nicholson in The Departed saying it) are just waiting to move on in to the iPhone. And if I were Steve Jobs and saw those “Do it now!” commercials, I’d cringe. I wouldn’t want those guys anywhere near my iPhones. And the AppStore does just that.
And part of the reason why we haven’t been bombarded by these “developers” on the Mac is because it’s not that big an attraction for them. The iPhone — unlike the Mac — is in the mass market. Everyone wants one and most people will get one.
They smell cheese.
March 11th, 2008 at 6:58 pm
@Mike, the official responder: Way to go, dude! Excellent responses since they are (a) fact-based, (b) concise, and (c) level-headed and keeping the tone of this discussion where is should be: on the SDK, and not where is shouldn’t be: reacting to every little perceived bit of chip-on-shoulder. Great job moving the discussion forward while leaving the hype and BS behind.
March 11th, 2008 at 7:02 pm
Is it possible that EDGE used for ordinary voice calls gives AT&T flexibility in making on-the-fly triage decisions (e.g. how much to compress the audio; what to do about missing packets; etc.)? They might not have any such flexibility with VOIP-over-EDGE.
March 11th, 2008 at 7:11 pm
Would VOiP over edge be any better quality-wise than simply calling?
March 11th, 2008 at 7:27 pm
To the responders on opening access on security - no of course OS X today is not a haven for malware. But that is for a variety of reasons, some including having a lot of variety in hardware and systems. I am convinced the Intel switch kept malware off macs for another two years at least, because of the difficulty of deciding which platform exploits you target! At any rate you cannot argue that OS X itself is at much greater risk of malware than is the iPhone will be as the SDK is set up, even if that risk has yet to be realized.
That the Mac has enjoy relative calm all does not mean that a new platform that is more homogenous and potentially fragile does not deserve higher considerations for security from the get-go. Think of it this way - using the AppStore applications will be purchased and used much more casually than they are on computers. This in turns leads to greater opportunity some trivial application to get loaded in your phone, and do something you do not want. With greater numbers comes greater exposure, the data on phones is also richer because people put so much key data on them. and that data is usually stored in a more standardized form.
Again I think it would be good to open some of the things you are talking about, but it’s better to start from a closed state and slowly open up now that we have a platform than can shed legacy baggage for what applications can traditionally do on a computer.
March 11th, 2008 at 7:49 pm
Another missing thing: there’s no apparent way to draw NSAttributedStrings, even though the class remains in iPhone’s Foundation Kit.
That’s my one annoyance.
March 11th, 2008 at 7:51 pm
This is a very interesting conversation.
I applaud your effort to provide this feedback to Apple and to more generally have this conversation.
I find it interesting that you keep bringing up the (somewhat simplistic) comparison to the Mac.
First an aside, this comparison does not make your argument right especially when you present mere assumptions as facts. (e.g. The iPhone and iPod Touch are, hardware wise, the rough equivalent of a midrange iBook)
But, may be more interestingly, that perspective of the iPhone / iPod touch as a “pocket mac” seems quite short sighted IMHO. That’s exactly what Microsoft tried to do with Windows Mobile… But apple seems to know better than that.
While I sympathize with some of your requests, I for one am actually glad that Apple tried something different.
Some of the restrictions (e.g App Store, no root acces, no access to the entire file system) imposed by Apple may very well turn out to be mostly beneficial and bring more “innovation” to the platform by forcing developer to think differently.
Gareth put it quite eloquently and I agreed with him.
= tmk =
March 11th, 2008 at 8:14 pm
hahaha….good luck with this!
March 11th, 2008 at 8:20 pm
It’s called iPhone 3.0. They’re not going to give us everything initially. We’ll all get 3G iphones when they come out, too. Note the road map is covered with toll roads.
March 11th, 2008 at 8:25 pm
David Rouse: “* Allow applications to run in background on iPhone — I disagree, again, speaking as a user. If I close my little AIM application, I am done with AIM — there shouldn’t even be an online/offline switch in the UI (again, speaking as a user — why should I have to take the extra step?).”
If you close the application, yes. But what if you’re IMing with someone and need to check something on the web? If the IM application can’t run in the background, you have to quit the application–disconnecting and, from your chat partner’s perspective, disappearing–and then re-open and re-establish the chat session. Even if the re-connection is made transparent from your perspective it will still show up to the other user.
Basically, anything that has to maintain a connection of some sort–and IM is a good example–can’t be used in combination with other programs unless it has some way to keep running in the background.
March 11th, 2008 at 8:30 pm
This just amounts to harassing and putting unnecessary busywork on Apple’s developers, who probably have nothing to do with these decisions.
Grow up.
March 11th, 2008 at 8:30 pm
@Andrew: It’d be worse, and would have frequent drops if you are anywhere but a metropolitan area.
Personally, no VOiP over EDGE is fine by me–I like having call-waiting. In fact, that may be a large reason why we have no background processes: nobody likes missing calls, and until iPhone goes 3G, why allow apps that ruin the fundamental function of it?
March 11th, 2008 at 8:43 pm
There’s definitely a need for background apps. There are two killer apps the iPhone needs in order for me to pitch it to my bosses: a secure password database application, and an SSH client.
With these two items, an iPhone would not only take over from my corporate-issue Blackberry as my on-call pager, but I could actually RESPOND to those pages FROM ANYWHERE.
But first I need someplace safe to keep the dozens of passwords I need to remember…
And I need my SSH connection to stay up while I check for a password. Or an address. Or take a call.
March 11th, 2008 at 8:54 pm
I want to congratulate you guys on taking the stand you are on the iPhone. It’s really refreshing to see Apple fans NOT knee-jerk agreeing with what Apple says.
I’ve been a Mac user for a very long time, and frankly, I’m pretty disappointed with the SDK. Sure it has some really, really good tools but I do not agree with the way Apple is handling application distribution. I’d really like to buy a PDA, I was hoping after the SDK came out I’d be happy with the iPhone/iPod touch platform, but I guess that won’t be happening.
I completely understand those who want their mobile phone to be as stable as possible. That is a legitimate concern. However, seeing as Apple obviously has the ability to disallow unsigned code from running on the iPhone, why not give users an option? Make the default “only run signed code from the App Store”, but give those who want the option to turn that off, letting their iPhone/iPod touch run whatever code they want to put on it.
I also do think the comparison to game consoles being made by some is completely off base. Apple clearly wants the iPhone to go after the smart phone market - which is essentially defined by having a more powerful phone that is a fairly open platform. Conversely, game consoles have always been closed, for a good reason. Remember that many modern games are multi-million dollar investments. An open platform would make piracy much, much easier and rampant piracy would be _disastrous_ for the game industry. That said both the PS3 and Xbox 360 do have some officially sanctioned “homebrew” - for the PS3 is is GNU/Linux and for the Xbox it is XNA. They don’t have the same access to the hardware as officially licensed software, but it is still quite a bit more than apps on the iPhone will have.
March 11th, 2008 at 9:05 pm
@Pablo:
Actually, it’s not. Apple’s WebKit developers actually encourage people to file a bug report if there is an API someone would like opened up. I don’t know what the iPhone SDK developers think, but it’s a fairly standard practice in software development to file a bug report for a “feature request”. The SDK developers themselves don’t have the direct authority to make such changes, but they are the ones who can pull some strings for the changes to be made. Again, this has happened before with the WebKit development. There were actually some APIs that were closed and the Apple guys filed bug reports _themselves_ and were able to convince the person in charge to open the said APIs.
March 11th, 2008 at 9:14 pm
Sorry, I think a lot of these “bug fixes” would be ruinous. I use a smartphone for work and I see the downside of treating the smartphone as a computer. It’s a disaster to use because I do believe that certain things need to take precedence over computer functionality. The phone functionality should be of higher precedence over all other aspects of the device.
March 11th, 2008 at 9:44 pm
Troy McFerron: You’re absolutely right that AT&T can’t be expected to allow VoIP given the choice. The problem is that they’re even in a position to dictate such terms. They should be a data provider nothing more, and not be in any position to discriminate based on the type of data which they carry. The whole American cell phone industry is far too incestuous, and this shows up in the case of the iPhone by Apple taking positions based on what’s good for AT&T instead of what’s good for Apple’s customers. VoIP traffic isn’t any heavier than “real” voice traffic. In many ways it’s actually lighter, because it often has better compression algorithms and doesn’t ask the network to prioritize it. The only “problem” is that AT&T’s pricing structure doesn’t let it extract revenue from VoIP. I believe this is a defect in AT&T’s pricing structure, and that is where the fix should be made.
Gareth: I’m certainly thinking of what I can do with this new platform within the constraints of the device. The problem is that the constraints of the device are much looser than the artificial constraints of the software distribution system. This annoys me. As for your claim that we need a gatekeeper to have a high-quality experience, my Mac is and always has been a high-quality experience and it has never had a gatekeeper besides me.
Troy Dawson: ZeroConf is a poor workaround for not being able to talk to the host computer directly. A non-trivial number of people do not have wifi networks at home. These people’s third-party apps will not be able to synchronize with their computer at all.
Andrew: You’re exactly right that an IM app should just keep going in the background and give you alerts even when you’re in another application. But the SDK as written does not let you do this. When the user switches to another application, your application is terminated and can’t continue running.
Chris: Thanks for being so kind.
tmk: I don’t really understand why you think that the equivalence in hardware between the iPhone and a midrange iBook is an assumption. The hardware specifications of the iPhone are well known. Compare them with a midrange iBook on a point-by-point basis, and you will see that, aside from the screen and keyboard, they are quite comparable.
nagha: I sympathize with that, so just make it an option. People who want phone functionality over all else can run in the safe zone, and people like me can run whatever they wish. As it stands now, we’re all forced into the safe zone even though many of us have no desire to be there.
March 11th, 2008 at 9:58 pm
Apple owns the iPhone. They can establish whatever rules they want.
They aren’t going to throw it wide open so any hacker can either purposely or accidently cripple the device.
There are plenty of serious programmers who welcome the chance to develop compelling applications for the iPhone and they realize some limitations are necessary, at least for now.
If you have developed the greatest app in the world but can’t do it without a wide open iPhone SDK, that’s our loss. We’ll look for it running on a competitors device.
March 11th, 2008 at 10:01 pm
While I would like to see many of these, but with many of them, I’m sure they have limitations in their contract with AT&T and we’ll never get them as long as the iPhone is under exclusive contract. The only one that is really killer for me, personally, is the inability to run code when your application isn’t running. Apple does this with mail and calendar, two of the higher profile applications, so they can’t argue that it’s not important, and most of the ideas for apps currently running around my head require at least a small amount of background processing.
There’s got to be some way for Apple to provide the ability to run a helper daemon or install a background thread without weakening security.
March 11th, 2008 at 10:29 pm
I’m checking it so hot (so hot)
I wonder if he knows he’s on my radar (on my radar) on my radar (on my radar)
March 11th, 2008 at 11:12 pm
Gareth: The Windows Mobile user experience sucks because Microsoft put a desktop UI on a mobile device, not because applications can share data.
Joe: Hundreds of millions of people depend on phones that can run unsigned code.
I think you’re making too much of the blame issue, but there are other ways to deal with that. On some devices, you can get full access if you agree to give up software support. Most Linux distributions have something similar in concept to the App Store; you can add other sources, but it requires a little know-how.
Apple Fan: Speaking from experience, the closed nature of game consoles has less to do with piracy than with licensing fees and content restrictions.
March 11th, 2008 at 11:14 pm
The trouble with the argument that the iPhone is not a Mac and that it therefore should be judged by different rules, is that everything that makes it different from the Mac is purely short-term. Eventually I have no doubt that computers will have cel phone network access built in, as more and more devices subsume each other’s functions. When Apple decides to add AT&T network access to your Mac, and then uses that to justify locking up software development, would you accept that? If not, then STFU about the iPhone being ‘different’.
It ain’t a damn bit different. It’s a computer that somebody has bamboozled into selling you while maintaining near total control over what you will do with it. It’s that simple.
March 12th, 2008 at 12:57 am
The arbitrary restrictions from apple are the reasons why I foresee jailbroken iphone to still be popular after the appstore availability…..
I want to be able to use my iphone on any cell phone provider I want (and since I don’t live much longuer than 3-4 month in one country at a time, this is pretty much a requirement), I want to be able to use VOIP on the cell network and for this I will still need a jailbroken iphone after the 2.0 firmware update…..
March 12th, 2008 at 1:17 am
hmmm …. do i want a handheld computer that allows me to do anything i want?
or do i want a phone that works?
that’s why apple has locked this environment down. they want the phone to work. seriously!
in time, this platform can open up like every other one, but for now, i trust apple to secure the platform.
thanks for reading.
- jo jo the dancer
March 12th, 2008 at 1:43 am
The Bug ID links don’t work for me, either as ‘rdar’ or ‘radr’ protocol on either Firefox or Safari. I’d love to add my voice to these, but I don’ t know how.
March 12th, 2008 at 1:53 am
I don’t disagree with any of your points and I can very strongly agree with some (especially the first). I think that your approach of notifying them that these are real issues for the developer community is a good approach. I know that I cancelled my plans to by an iPod Touch when the SDK limitations were announced.
I can’t justify buying a device that I can’t hack code for, in this day and age, and I don’t want Apple to have to ok every little tool I hack together for just me to use.
In terms of distribution, what happens if Apple suddenly decides to turn off the spigot because they want to release an app which competes with mine or because they don’t like it on some technical or moral level (since Apple is now the nanny, since their confusing stance against porn applications - whatever that means)? Do I get to field a million support calls from angry customers (who now want 100% refund for an app for which I only received 70% payment)?
Given that Apple holds to kill switch for every app on the platform, I doubt many companies will want to absorb that liability. Even in development, what happens if you put countless developer hours into developing an app that they won’t sign? I guess you better ask those poor guys for their pay cheques back, eh?
March 12th, 2008 at 2:22 am
@Tod E Kurt: rdar links are for Apple’s people to give them (and only them) one-click access to these reports. To add your voice, just file a new bug report using Apple’s bug reporter. If you’re feeling like saving their engineers some trouble, mention the original radar number. I don’t think that hurts at all.
More info on Radar links on Rentzsch’s site.
March 12th, 2008 at 2:30 am
Although I don’t particularly agree with most of the “bugs” that were filed (or the idea of mixing these kinds of complaints in with actual bugs), I must give the Rogue Amoeba guys credit for voicing their concerns and sparking this excellent debate. A lot of people took the time to think about the implications of this emerging frontier and share their perspectives, and many great points have been made.
I haven’t really got time to dive in with my own comments right now, but just wanted to thank everyone who participated in this thread for a worthwhile read.
March 12th, 2008 at 3:07 am
For those of you arguing against VoIP over the cell network…
While the iPhone doesn’t have 3G yet, and my Nokia n70 isn’t full 3G, I was still able to use it (the nokia phone) as a bluetooth modem to my mac, and used it to run Skype. But I did more than just talk, the network was fast enough to support video chat. Why? Its just data.
What really surprised me though, when I switched over to a wifi connection on the mac, (operated by another telecommunications company), the quality of the video was worse.
Finally, why is VoIP a big deal? Its simple, its not about being able to call someone in the same country, its about cheap international calling.
March 12th, 2008 at 3:09 am
I haven’t really dugg into the SDK enough to be qualified to make a statement on all of it.
But:
I agree with most of the points you are making.
Especially the background service thing. It is ridiculous, if it is impossible to run apps in the background. That is simply necessary.
I also don’t see the point, why the media files shouldn’t be accessible (I can of course imagine that some insane copyright infringement paranoia sits behind that).
Wanting to have Airfoil on the iPhone, I have to agree that this sounds like a major disappointment.
Root access is probably another one of the paranoia points and in terms of security and stability a potential risk for SOME people.
So I reckon this kinda makes sense.
I couldn’t care less about the VoIP thingy tho. I don’t see myself using EDGE for that. HSDPA is another thing, but then again, no, wouldn’t use it either.
I like the idea of the AppStore with the hope that that ensures a certain quality of the apps.
And I have to admit, although I am not really using the iTMS very often, it is working extremely well on iPhone, so that isn’t really a big deal.
The simplicity of that is a pretty good reason to use it.
The Dock Connector part? Not sure about that one. I hate to imagine myself plugging something in there. I know there are a lot of people out there who want GPS solutions, but I just can’t stand the idea of having something sticking out there (breaking off eventually).
I have to say, so far I like the iPhone in it’s default configuration and the enhancements Apple made. I wouldn’t wanna see it ruined by apps with fugly icons, UI or awful hardware enhancements like that GPS add-on.
There are, however, excellent apps out there (Airfoil is one of them) and I would like to see those on the iPhone as well.
One thing I don’t understand is that public whining about everything Apple comes out with lately. MBA, SDK… it’s all not good enough.
I don’t see how making iPhones more Windows Mobile/Symbian OS like, will make it a nicer device. That’s what’s gonna happen, if the entire platform is totally open to everyone.
That may sound like an elitist opinion, but I have seen too many horrible things on other OS and platforms.
People have enjoyed Apple’s policy for all those years and the advantages that this brings as well. Suddenly all of that isn’t good enough anymore? Don’t think so…
I understand that people will always want more, but that will take time and I rather have Apple making some more of the implementations than having to deal with a flood of things from 3rd party manufacturers that might not be providing the standard I am used to.
This is totally subjective, but I’ve been using too many OS X and iPhone apps that are simply put disgusting and unstable and I don’t want more of that.
Having too much (choice) isn’t really always a good thing.
March 12th, 2008 at 3:13 am
It will be interesting to see whether these limitations are trial balloons or not.
I hope that they are, and that Apple continues to iterate their SDK strategy until they hit the sweet spot required to decisively win the hearts and minds of the developer community.
Apple’s history with developers gives some reason for skepticism, something that I recently blogged about in, ‘The Scorpion, the Frog and the iPhone SDK.’
Check it out if interested:
http://thenetworkgarden.com/weblog/2008/03/the-scorpion-th.html
Cheers,
Mark
March 12th, 2008 at 3:49 am
since most of the concerns people have with a more open model have to do with the reliability of the PHONE i suggest a model where the iPhone would be closed and controlled whereas the touch would be a more open, adventurous and geeky toy.
this would keep AT&T happy and all the 911 calls safe. developers could prove their point on the iPod and if they succeeded the more open model could then be adopted to the iPhone.
of course this will never happen since apple needs to keep iPhone superior to iPod touch.
personally i would love to use the touch a bit like i used the original palm to which i installed an ingenius japanese system wide wiki-hack. and whenever out of wifi randge my touch would contact my finnish 3g network via a small phone in my pocket.
ps. please someone make a simple vector-based drawing app for the touch for me to sketch typography and such on the tram. ok, i must confess i’ve been waiting for a tablet mac for at least a decade now so i’m propably not a typical mac user…
March 12th, 2008 at 4:57 am
I couldn’t agree more and filling bugs is Apple’s preferred way of getting feedback, so by all means use it.
Some people compare the iPhone SDK with other telco schemes. If that’s your point of view, yes Apple is doing a great job.
Don’t forget, however, that while most “smart phones” are merely toys, the iPhone is a pretty much fully fledged tablet computer. You can do a lot more with it than just place phone calls and keep to-do lists.
There is of course also the vastly successful iPod Touch. That certainly isn’t a smart phone and it’s hard to argue (even though some do) that it should be restricted in the same manner as a Nokia or Pocket PC phone.
For me, and I believe many actual users of the device, the iPhone SDK is for developing nano-Mac applications. I can’t see why Apple should get to play the monopolist card, while customers and developers are deprived of choice.
If Apple’s move is really in the best interest of its customers, they should let the customers make their own choices. If they’re right it would do no harm, because everybody would choose Apple’s way.
If it’s the telcos putting on pressure, unlock the iPod Touch and let the iPhone continue as a restricted device.
That last proposal is of course pure fantasy, because Apple knows full well that there would be lots of people shunning the iPhone in favor of an unrestricted iPod Touch if they did that.
Which is my point. Customers, not all but an awful lot of them, would prefer a “free” device from one that is entirely controlled by a monopolist. Even if it is a well meaning one and has got a charismatic front-man.
Apple pays lip service to the principle of an open platform and invites feedback on the SDK and the App Store. My feedback is “open it up!”.
BTW I’m not an Apple hater. On the contrary. I just prefer open solutions to closed monopolistic ones.
March 12th, 2008 at 5:28 am
@Paul
Quoted message:
> Add option to allow iPhone applications to access entire filesystem
>
> To do interesting things, some applications need access to data beyond
> what they create. Image and Contact Picker are a start, but what happens
> when a suite of applications is made by one company? How will one app
> edit another app’s data? This is an extension of needing a MediaPicker,
> but it would be much broader and more powerful.
While I agree about the need to access to other apps datas, I totally disagree about the solution you propose, which is access to the entire filesystem.
For security reasons, this is a bad solution, and a far better one, which will be as flexible but far more secure, would be to allow app developer to expose APIs of there apps…
Frankly, I don’t know if it’s possible as the SDK is, I didn’t investigated that much yet. But if it’s not yet possible, that would be the real good solution for accessing other apps data.
This way, you are sure that other apps access only data of your apps you want them to be able to use. And this is far more clean, and can even be easier to use for developers.
Sadly I can’t post that comment on the enhancement filled in the apple bugs reporter as I’m no Apple engineer, but please take that in account, and if you find it interesting, suggest it as a potential alternative (if it’s not already possible with the current SDK).
March 12th, 2008 at 6:02 am
Apple’s Rights / Hacker Rights
I’m not sure its worth getting angry at Apple over these limitations. They appear to be acting in their own best interest to grow a new platform. And that is as it should be. They obviously have some ideas about how to create a powerful new mobile computing platform like the world has never seen. And, let’s not forget, the iPhone has been quite successful to date, even with no legitimate 3rd party software at all.
I think that the decisions that Apple has made are not to punish developers, but rather to try to protect their customers from some of the shortcomings of other platforms. As well as to move cautiously with growing their infant platform so that they aren’t eaten alive with claims of instability, insecurity, etc.
As noted above, the SDK also goes a long way toward allowing those who just want to hack the iPhone to run custom apps a much cleaner way to do it. So, even though Apple has created rules to prevent easy distribution of such apps, and to especially keep such apps was being associated to the Apple brand, they have also “opened” the iPhone for hacking in an appropriate manner. Unlike, for example, the Xbox360 or the iPod.
I think Apple’s approach is really just an attempt to balance the desires of all the stakeholders, including 3rd party developers, customers, hackers, and AT&T.
March 12th, 2008 at 6:02 am
Picking up the VOIP issue:
First, VOIP over EDGE data is MUCH less efficient than making a GSM voice call. Sorry to anyone asserting otherwise, but it isn’t ‘just data’. The GSM voice systems have been very highly optimised to reflect exactly how the GSM radio link works. IP hasn’t, and (say) Skype certainly hasn’t, and radio data is a pretty hostile environment for IP. That means that making a Skype call uses several multiples more radio network capacity than a circuit-switched voice call. From a telco’s point of view, that’s pretty much the end of the discussion. This will change with HSDPA, but on EDGE, there is no technical justification for VOIP.
Then, there’s the economic issue. Sure, you can use VOIP to get cheap calls - but only because they’ve given you capped minutes but uncapped data. This is merely an arbitrage play. Either operators ban VOIP, or they cap data, or they charge you more. Ultimately, if you use the network you’re have to pay. If the pricing structure doesn’t reflect how you’re using it, then they’ll change the pricing structure.
March 12th, 2008 at 6:10 am
First - this has been said several times in these comments and elsewhere, but people don’t seem to get it, so let me repeat it again: the iPhone is not a pocket Mac. The iPhone is not a pocket Mac. The iPhone is not a pocket Mac.
The iPhone is a wholly different device, with a different job to do and a different set of expectations. The iPhone can do things that a Mac cannot, and a Mac can do things that an iPhone cannot. The interfaces are wholly different. The end-user expectations are wholly different. The operating parameters are wholly different. As a result, the software ecosystem needs to be wholly different.
Please stop trying to make direct comparisons between the Mac software ecosystem and the iPhone ecosystem.
Your wanting a pocket Mac is a wholly valid desire. However, it is not (and should not be) a desire satisfied by an iPhone. I believe you want a completely different (and unnanounced) device.
As for those who claim to prefer “open” handsets and handhelds - why on earth would you have bought an iPhone in the first place, then? It is not, never will be, and was never claimed to be open in any possible sense of the word. In fact, it was always one of the most locked-down devices right form the start. If you want an open device, why are you not supporting something like the OpenMoko initiative?
March 12th, 2008 at 6:53 am
Hi guys,
Some points are pretty right I think.
I’m from Appledifferent.com and I’d like to ask about 3 or 4 tiny questions to Paul, since I think he deserves an itv.
Is that possible ?
March 12th, 2008 at 9:25 am
Whilst the iPhone maybe more powerful than a decade-old Mac, the one key feature the iPhone lacks is a swap file. Implementing one would not be good for NAND Flash either.
I had a jailbroken iPod Touch, and not sure which apps I’d installed, but the Touch was crashing infinitely more than when I’d left it alone. No doubt due to the odd application that hogged too much memory or something, either way uncontrolled app installation was a detriment to my iPod Touch experience.
And then there’s Windows Mobile, if there’s a case for a closed/controlled environment it is WM. The quagmire of shitty applications with really poor performance (usually due to writing the mobile app the same way as a desktop app) is huge. My WM device had to be rebooted every two-three days, because it became too unresponsive. There was never enough memory to load hardly any of the applications (even though there was a good 32+MB of Program and Storage Memory left available. Even the phone part of the device would stop working (with no indication it was broken).
Controlled is definitely good.
Sandboxed is definitely the way to go, especially with an “always-connected” device that could hold sensitive personal data.
As for VOIP over EDGE, check the contract on your iPhone (whatever the country) and you will discover that using a “continuous streaming service” over EDGE is against the Terms and conditions of your contract. VOIP would count as continuous streaming, as the stream would remain active until you ended the VOIP call (same as listening to an Internet Radio station).
Apple can’t be slagged off disallowing EDGE streaming, because it isn’t their decision to allow/disallow it, it’s a restriction put in place by a third-party.
March 12th, 2008 at 10:00 am
Terry W: Modern flash has wear leveling algorithms which allows it to be written to continuously for decades (that’s full-bandwidth 24/7 writes for roughly 50 years) before it wears out. Using swap on flash would be just fine and cause no harm, and it would be a lot faster than on hard drive based devices too. Note that the MacBook Air has a SSD option and it will swap to it. Even swapping to it continuously, the flash drive will be the last component of the device to die.
Yes, VoIP is probably prohibited in the service contract, I won’t dispute that. But I don’t see why that means Apple has to prohibit it. Or rather, I do see, because Apple and AT&T are joined far too closely, but I don’t think it should be that way. Just because Apple has to do it doesn’t mean that we shouldn’t register our displeasure about it.
March 12th, 2008 at 10:07 am
I just think of it this way - Apple believes developers are evil or dumb and that consumers are just plain dumb. That’s why they want to approve every application before it’s released to the wild and why they want to prevent consumers from adding any app to their phone.
March 12th, 2008 at 10:17 am
Dogzilla:
Some people may want a Pocket Mac, but most of us just want a revolutionary mobile platform. While a few of these bug reports may have more to do, perhaps, with philosophical differences, some of them are reporting issues that will actively prevent the types of mobile apps people are going to want from being written for the iPhone using the official SDK.
The RA folks are not asking Apple to make the iPhone the same as the Mac, they’re asking them to give us enough freedom to make it a more compelling platform.
We are all aware that Apple (along with AT&T) gets to make the final decision on all of these, but that doesn’t mean we shouldn’t let them know where we think they’ve made a poor decision. Apple has changed course in the past based on developer feedback and may do so again if they are presented with compelling enough arguments. But if we behave like the sheep and accept any decision that they make without complaint, then we deserve what we get, much the way the Windows Mobile developers have gotten what they deserved.
March 12th, 2008 at 10:22 am
Amit:
Exactly what basis do you have for saying that Apple believes developers are dumb? Just because they made some decisions you don’t agree with? You have no idea the factors that went into those decision, so how can you possibly understand the motivation or reason behind them.
It’s one thing to let Apple know where you think they’ve made a wrong decision. Rogue Amoeba is doing just that in a respectful with thoughtful manner that has a chance of achieving results. Making uninformed assumptions about Apple’s intentions behind those decisions is not going to change things.
Besides, you are free to develop for a less “evil” platform if you can find one.
March 12th, 2008 at 10:28 am
Your wishlist, for the most part, is a recipe for potential disaster. Frankly I hope Apple ignores it.
March 12th, 2008 at 11:21 am
@gareth ,why do you think it’s your right to dictate what I can WANT on my iphone. You are an absolute tool–with no vision. I agree with Apple’s approach, but to insinuate that there are only a few valid apps that anyone should need is utterly ridiculous.
I have often wished I could scribble a note on a photo, crop it, and even do some simple vector illustrations as an overlay. This doesn’t take into account all of the crazy uses the verticals will come up with for the iPhone. Don’t be so presumptuous to think you are the terget user for the iPhone. frankly, you sound like a sheep that would have agreed with whatever was announced.
March 12th, 2008 at 12:42 pm
David Rouse said
David - I think you miss the point on this issue. Several of the applications that come on your iPhone that were written by Apple use background processing that wouldn’t be possible if developed under the SDK. For example, mail wouldn’t be able to periodically check for mail without this; calendar wouldn’t be able to notify you of appointments without it. Do you really want those things to stop happening when you close Mail or Calendar? There are valid reasons why third party developers would want to have this ability as well; I have several ideas for apps that can’t be done without this ability. It will be invisible to you as a user, but it is needed.
March 12th, 2008 at 2:16 pm
I haven’t had time to play much with the SDK yet, but the inability to share data between desktop and iPhone app seems like a major blunder to me. That knocks out all sorts of interesting ideas. So I’m stuck with writing a game — not what I was looking for. Or use the web to synchronize data between the iPhone & desktop — oh joy!
Apple’s own application prove the need for being able to share data. Just how useful would Calendar and Contacts be if they couldn’t share data with their desktop counterparts?
Another Bug logged.
March 12th, 2008 at 5:15 pm
A couple of things:
1. Guys…you are treading dangerously close to NDA violations. A couple of things discussed already are VERY “Fight Club”
2. It is VERY OBVIOUS that the SDK platform is, for want of a better phrase, a “Web Apps Plus” platform.
That is to say, the types of apps they are…”looking for” are more like web apps in their scope, with some hardware love for a little more power.
None of this surprises me…and I’ll tell you why.
About 3 mos ago I contacted Thawte about app signing keys for Mac OS X and they noted that the certs Apple were using implemented remote revokation.
That, and a little 2nd party info from an “underground” dev that apple had contacted about their app because of the specifics on how it worked gave me a pretty good idea that apple’s distro was going to be a walled garden approach akin to what Verizon does with the BREW platform.
Virtually no existing Mac desktop apps fit into the scheme Apple has in mind.
What is most interesting tho, is that Apple’s customers by and large are perfectly happy with these proposed limitations…and at the end of the day, that is the voice apple will listen second.
First of course, will be the guy at corp hq that counts all that fat money pie they are going to be chowing down on.
March 12th, 2008 at 11:54 pm
I would still want some limitation. Looking at some legal stuff. If you get your own source of application. The developer had a bug that meant extra cost for you with AT&T. Now you get a $555,555,555 invoice and can’t afford it.
You make a lot of noise and blame Apple. Well you should only be able to do that if Apple could have stopped you from installing the application and they didn’t. If you defeated they means and went ahead, do you get the developer to pay for it? But they said in their licence that it’s all your fault.
Put limitation, take some off slowly and carefully. What gets done there could potentially mean have to fork out $$$$.
March 12th, 2008 at 11:56 pm
“Allow applications to be installed at the user’s discretion, not Apple’s”
Applications will be installed at the user’s discretion. Apple isn’t going to come into anyone’s house and force the occupants to download something.
What you’re really asking Apple to do is “Allow developers to distribute malware.” (Yes, I know you’ll disagree, but that would be the result.)
There are some good suggestions on your list, but you undercut your credibility with unreasonable, ideologically motivated stuff like that and your request that Apple allow you to siphon off AT&T and Apple revenues with VoIP.
To prove it, you say, “This is perhaps the most important issue - if this restriction is lifted, many others become far less important.”
Technical issues become less important simply because Apple accedes to your notion of the politically correct way to distribute software? I don’t think so.
March 13th, 2008 at 2:32 am
A few of those restrictions do have a specific purpose, and I agree with them, even if they restrict some of what I can do. The big one is, installing an unsigned app. As an end-user, sure I’d love to be able to do this. But as a developer, think of the repurcussions. First off, allowing unsigned apps enables piracy - not immediately, but it wouldn’t take too long for pirates to figure out how to “unsign” an app. Piracy will happen anyways, but this makes it so far fewer people will actually do it, than if they could download any darn thing they wanted from anywhere and install it.
Second, this keeps the lowest of the low garbage shovelware off the system - you gotta pay $99 to distribute anything. I mean, say I write an IRC Chat app. I go to a lot of effort to make it look and feel like the other iPhone apps, adding plenty of sparkle and neat effects, while keeping it easy and quick to use. I pony up my $99 and put it up on Apple’s store for $5. But then Homebrew X straight-ports a crappy old Windows IRC client and posts it all over the internet as a free unsigned download. Suddenly, nobody wants my $5 app anymore, because there’s this free app out there that can do the same thing; sure, it isn’t as nice, but people won’t know how nice mine is without trying it, and even then, free generally beats money regardless of quality. Heck, after a few months most people probably won’t even bother to check the official store, since they can get all sorts of free apps from elsewhere.
Admittedly, this situation can still sort-of happen with the current system, but it’s far less likely, because of that $99 fee and the limitation that you can only install stuff you find at the same store you’d see my snazzy version.
March 13th, 2008 at 6:16 am
@ Mike
You wrote “The hardware specifications of the iPhone are well known.”
My google searches only reveal various speculations, not facts about what the iPhone hardware specs could be.
Care to point me to “well known” specs that are not mere speculations? That would be much appreciated.
Anyway that was an aside.
My main points being that:
- first comparing the iPhone / iPod touch to a Mac is irrelevant and misguided .
- second that the perspective that the iPhone is (or should be) a “pocket mac” is IMHO wrong and shortsighted.
Another thing, I’m sure that *you* personally are a great gatekeeper for your devices as you’ve repeatedly written and I don’t think anyone is disputing that :-).
Where your argument is flawed is when you imply that because *you* are then other users would be as well. Gazillions of infected Windows computers have demonstrably proven how wrong this view of the world is.
I know I would be the more appropriate gatekeeper for *my* devices but until a better solution is found I also know that it makes sense for Apple to be the gatekeeper for all iPhones even though I’m not confortable with one third-party dictating what can or can not be installed on my devices.
March 13th, 2008 at 6:17 am
sorry, meant to write “not facts about what the iPhone specs *are*” in the above comment.
= tmk =
March 13th, 2008 at 8:05 am
@tmk
i’m sorry, i think your argument is flawed. using windows as an argument in favor of an apple/iphone nanny-state just doesn’t hold water, imho. we all know there are lots of reasons windows is so ridden with malware, the users only being one, and not the most significant, i think. windows has a long history of bad security practices, exploitable bugs, etc. apple does a good job of enforcing good security practices and providing a stable platform. are you really suggesting that apple just has wiser, smarter, better-looking users, and therefore less malware?
so why can’t this be the case with the iphone? i hope it will ultimately go in this direction, and that apple will listen to users and developers, and that they are smart enough to figure out good ways to accomplish a more open platform without compromising its stability. i, for one, believe they have the smarts to deliver more, and i’m all for the community pushing them in this direction. if they have great reasons not to do these things i hope they’ll explain them (i’m not holding my breath, it is apple, after all).
March 13th, 2008 at 8:17 am
The truly threatening aspect to me of all this is how many people see what happens and aren’t upset or even agree on Apple’s policy.
“I don’t want to install an application if Apple doesn’t sign it”
Even sheep isn’t behaving this way.
(Signing doesn’t mean testing or certification, btw)
You can even have this attitude, no problem for me. But if you don’t have it, the iPhone just became dust, and this upsets me.
If all these security and morality problems really existed, Windows Mobile would be existing anymore. All kinds of applications, from everywhere, no limitations (except those from the documentation ;)
I’ve never had a problem caused by this and I don’t know a single owner who did.
I’ve had lots of good applications (eg media players, navigation etc) even for free for my old WM device, and I’m close to going back, if Apple doesn’t change their policy.
March 13th, 2008 at 8:50 am
@Jeff: “The RA folks are not asking Apple to make the iPhone the same as the Mac, they’re asking them to give us enough freedom to make it a more compelling platform.”
But there’s the rub, isn’t it? On the one side, you have a number of developers asking for deeper access to the iPhone in order to make it more compelling. On the other side, you have internal Apple folks deciding that gatekeeping and limitation trumps freedom in order to make the iPhone a more compelling platform. Apple’s side has an existing proof-of-concept in WMA, where the freedom has *not* developed into a garden of compelling apps, and instead has developed into an untamed bramble of junk and borderline malware, with a few isolated islands of utility. Having come from that world, I value the stability and elegance of my iPhone *above all else*. Others may feel differently, but it’s hard to say that Apple’s approach isn’t a successful differentiating factor, as it’s outsold just about every other similarly-capable phone on the market. Again, I refer developers who want this type of freedom to OpenMoko and (perhaps) the Android platform. If you feel the iPhone is a more compelling platform, is it not reasonable to believe that Apple’s design decisions are at least part of the reason for that success?
@Generally: I’ve seen a lot of generalities spoken about here. But I would like to see some specifics on how these freedoms would be used, so that we can discuss the real advantages they would deliver and weight them against the real security holes they would create. What exactly do people want to access other apps data for? What do you want to run a background process for, and how would you expect to be able to do it? I think it’s far easier to find fault than it is to offer an alternative, and I’d like to hear what some of the alternatives are from a developer’s point of view.
March 13th, 2008 at 9:21 am
Mr. X: The reason that allowing the installation of unsigned apps trumps all the rest is simple. If that happens, I can do anything I like to work around the other restrictions. There will be holes in the sandbox and I can use them to escape (with user permission, of course). But if everything must be Apple approved then I can’t even attempt this, because Apple will reject me.
tmk: Wikipedia has the specifications with sources. Gazillions of Mac users have demonstrated that having the user run his own machine works just fine.
March 13th, 2008 at 10:49 am
I’m appalled at the level of excuse-making offered here. How utterly pathetic. Do none of you remember Apple’s disaster of trying to control apps on the Newton? Or that train-wreck that was eWorld? Apple has no business butting into how developers release apps for a device and you’re all just pathetic fanboi’s for pretending otherwise.
March 13th, 2008 at 11:19 am
Now is Apple going to really test *every single* app that gets submitted to them? Or is that something that’s going to remain mostly in the developers hands? In that mode, I could see why having a certificate is somewhat useful: If they see enough reports of people who had app X installed and something what haywire, they can say “something needs to be fixed” and if nothing happens they can then say “all right, you’re out.” Along with the right to develop and distribute apps comes the responsibility to not make crappy ones. I un-jailbroke my phone after something (either Installer.app or Apollo) was constantly on the network and I got 5 hours of battery life. Since Apple is going to distribute these, they’re effectively putting their seal of approval on it and I’m sure they want there to be some level of quality.
Another questions: Does AT&T need something on their end for AIM to work the way it does on the desktop? It seems like a lot of other AT&T phones have AIM on them out of the box, though I don’t know if that runs in the background or if it’s effectively SMS.
Finally, would there be a way for a third party to build some sort of ActiveSync-style app for .Mac? A way for me to bounce calendar appointments and contacts off of .Mac and sync them down to iCal and Address Book? The other day I had to change to appointments in iCal and it seemed a bit of a hassle to to plug in and sync given the changes I made.
March 13th, 2008 at 11:30 am
I appreciate the topic. My list of demands for Apple is as follows. Given Apple’s objectives with this SDK and their desire to protect their markets I think my list is reasonable.
- Data Syncing Services
You address this as “Allow iPhone applications to access the host computer when docking”), but a nice first step would be just any way to allow developers to move their own data files to and from the desktop when docked. Currently our only sanctioned options are over the internet (e.g. FTP).
- iPod media player library access
I understand Apple doesn’t want Amazon creating a music download app. But Read-only access to the library would be quite to many non-competitive music playing applications.
- Access to Calendar data
We get addresses, why not appointments?
- Sharing data or interprocess communication
The sandbox is fine. I can’t touch your files. You can’t touch mine. But a designated common file area would go along way toward addressing the lack of any interprocess communication facilities.
March 13th, 2008 at 12:15 pm
I also believe that using an engineer’s bug-reporting mechanism for business feature requests is an abuse of the developer interface.
But let me express it in more of a political context: if YOU were Apple, would you be more interested in reversing yourself by granting exceptions, escalated privileges and whatnot, to a firm that shows itself aggressive in misusing the general privileges?
There’s a perfectly obvious justification — sometimes, two or more — behind EVERY one of the Apple restrictions, generally along the “security,” “performance,” “SDK immaturity” and “user experience” lines that other comments spell out above.
If I were looking for, say, a mechanism to access my PC across the dock, I’d expect to tell Apple (1) why this represents a bigger opportunity than a problem for them, and (2) a mechanism that would allow them to control the problems at a reasonable cost. Instead, this post deprecates Apple’s business sense; NOBODY would run this stuff to somebody HALF as mercurial as Jobs is often said to be.
It’s just foolish and naïve to expect Apple to turn the iPhone into the world’s second biggest malware magnet. Likewise, to expect that they’ll actively collaborate in screwing their business partner networks. And that perfection comes instantly, especially given the difficulties that EVEN customers of Rogue Amoeba have had in adapting — e.g., Airfoil — to the much more stable Mac OSX environment.
So what’s really in it for R.A. to carry on this crusade this way?
March 13th, 2008 at 1:29 pm
Your view of how bugreport.apple.com is to be used is flat out wrong.
Let me just copy part of the topic in the #iphonedev IRC channel (which was set by a DTS engineer from Apple)
Apple DOES want you to use the bugreporter to respond with feedback. The bugreporter is the ONE and ONLY way to do this officially. When a developer files a report through the website, it goes into Apple’s internal Radar bug tracking system to be dealt with. Feature requests, enhancements, and yes bugs all go there. Radar is institutional memory for Apple and a way for managers and engineers to figure out what to work. If a rash of developers file reports related to the same thing, that gets the attention of management and leads to it being addressed.
So what’s in it for RA is for the ability to voice concerns they have with the development environment. Do I agree with all their issues, no. Do I respect their right to do so, yes. And I encourage every other developer who has an issue of any kind to do EXACTLY what RA is doing.
March 13th, 2008 at 1:31 pm
Excellent conversation! But some perspective…
Apple invented the Mac, the iPod/iTunes and the iPhone which are hit products. Like any other company, they’ve produced some misses, too.
Just like you would feel if you invented something amazing and wanted the maximum revenue from it, we need to remember that this is Apple’s product, they spent the money inventing, developing and marketing it, and they can do whatever they please to present it in whatever way they see fit.
Apple is unique in its own way. By controlling both the hardware and the software, the Mac, iPod, and the iPhone are superior experiences, less prone to the degenerative effects of the free-for-all that other more open systems experience, e.g. PC, Treo, Windows Mobile, etc
The Mac is over a quarter-century old and it still shines. The iPhone is not even a year old, and the SDK is now a week old.
Be patient. This is Apple’s product, not ours. They are letting us in on a piece of the action and/or a piece of the glory. Take it easy. If the genie gets out of the bottle you’ll never get it back in. Better safe than sorry.
It’s amazing how much hubris some people have. This is Apple’s product, not ours. Did I mention this is Apple’s product?
Remember the early days of the Mac or the iPod? They seem so primitive compared to now, but things took time. Quality products that [continue to] stand out from the rest take patience and consideration. First we had only web apps, then we had a restrictive beta SDK, and then we had… And in the end, there was a great product with long legs that, still, no one else could touch.
Thanks for listening.
Mark
March 13th, 2008 at 2:58 pm
Guys, I completely agree with you, but I suggest you expand on the reasons for all the things you ask for and that you anticipate Apple’s answers to these requests and why they might not be right in their restrictiveness.
Great article.
March 13th, 2008 at 4:41 pm
@Bill Kearney
“you’re all just pathetic fanboi’s for pretending otherwise.”
Calling someone a fanboi is so tired. It stopped being funny or clever about 5 years ago. It’s like saying “Why don’t you ride your Razor over and watch this crazy new show called ‘Survivor’? We can complain about all the dot-commers!”
March 13th, 2008 at 5:41 pm
Michael Tomlin, etc.,
Apple is always asking us to file feedback through the bug report website. This IS NOT SPAM. How do you think we got the expanding menus back in the Dock with 10.5.2? Through constant user feedback. At WWDC, Apple is always telling us to file bug reports for anything we think should change and they will consider the change and do what they feel with it. If enough people are filing bugs/change requests, then Apple will listen.
There’s already 100,000+ downloads of the SDK in only a few days and if 10-20% of those users file similar requests then Apple will probably listen.
March 14th, 2008 at 11:45 pm
Very interesting discussion going on here, we are talking about this article over at iPhoneDevForums.
http://iphonedevforums.com/forum/index.php?topic=20.0
March 16th, 2008 at 10:17 pm
http://furbo.org/2008/03/16/brain-surgeons/