6 ms·

I totally agree with some of the points: iOS should really receive the same garbage collector that OS X has had for years, and the provisioning certificate nons

I totally agree with some of the points: iOS should really receive the same garbage collector that OS X has had for years, and the provisioning certificate nonsense is, well, nonsense. iOS really does need a side loading mechanism. That you need a Mac to develop on is, I suppose, a negative - you can get going with Android on almost anything. However, I can't say I've ever had any problem with Apple's documentation: It's clear, well written, generally entirely correct. I must confess, I've never spent "weeks devising and performing increasingly peculiar experiments to figure out how to get iOS to do what [I] want", any more than on any platform. If he's complaining that iOS has private APIs then, well, I'm quite sure Android does as well - private just means "not guaranteed to exist in the same form on an upcoming release". If he's claiming that Android's "openness" allows him to see deep inside the OS to make design decisions, rather than relying on the documentation, then I'd suggest that's a mad development strategy (unless one likes rewriting when new OS releases come out). The point about the simulator seems to be that Android's is so bad, you have to use the phone. I can't really see that as a plus, as one could do exactly the same thing on iPhone, except that iOS has a working simulation environment for when you want it. The remaining points, about the initial user experience and development environment are entirely subjective, so one can't really comment either way. His point that developing for Android seems to be "easier" than iPhone runs contrary to my experiences, but what one man finds easy, another might find hard.

mickdj 16y ago
Clarification: We don't use any private API's on iOS, James' comments were with respect to what we do with location and networking. Apple's documentation is great for most visual elements, but CLLocation* in particular has quite flawed documentation.
- pkaler 16y ago
  Where are the flaws in CoreLocation or the documentation? CLLocationManager is instantiated like any other NSObject. CLLocationManagerDelegate returns asynchronous results like any other protocol in Cocoa/CocoaTouch. CLLocation, CLHeading, CLRegion are about as close as you're going to get to get to C-style POD structs in Objective-C. The documentation is all here and the API is about straight forward as it is going to get. http://developer.apple.com/library/ios/#documentation/CoreLocation/Reference/CoreLocation_Framework/_index.html http://developer.apple.com/library/ios/#documentation/CoreLo...
  - mickdj 16y ago
    I don't want to veer O/T, but that's not the hard stuff in CLLocation. There's a lot that could be discussed, but as one example: optimizing for battery conservation requires knowing which radios are currently powered up. iOS makes its own decision as to which of the 3 styles of location service to engage, based on the desiredAccuracy and distanceFilter values. However the WiFi/GPS radio have different costs for runtime and warmup, so this API doesn't help when you are attempting to optimize for all 3 of: Accuracy, Timeliness, Battery conservation Furthermore, the accessible battery percentage in UIDevice.batteryLevel is only reported to the nearest 5%, which is not granular enough to be of use in real-time server-based tweaking.
    - pkaler 16y ago
      There's a lot that could be discussed... There isn't a whole lot to be discussed. iOS minimizes battery usage based on how close cell towers are, type of cell tower, altitude, Wifi spots database, state of GPS almanac, hardware/driver combination, etc like a any good OS/kernel (including Android) should. The App sets CLLocationAccuracy to kCLLocationAccuracyBest, kCLLocationAccuracyNearestTenMeters, kCLLocationAccuracyHundredMeters, kCLLocationAccuracyKilometer, or kCLLocationAccuracyThreeKilometers and that's it. The OS will almost always be able to minimize battery usage because it has way more information than the App could or should ever have. The App will never be able to optimize this setting because there will always be new hardware with new tradeoffs. Your claim is that Apple's documentation does not describe the implications of the laws of physics for an arbitrary location that the user may reside at and does not reveal implementation details of the kernel that change every hardware/software revision. The API could not be much simpler or much better documented. Do you really think that Android's documentation is better? http://developer.android.com/guide/topics/location/obtaining-user-location.html http://developer.android.com/guide/topics/location/obtaining... http://developer.android.com/reference/android/location/package-summary.html http://developer.android.com/reference/android/location/pack... Because the Criteria class on Android is essentially the same as CLLocationAccuracy. http://developer.android.com/reference/android/location/Criteria.html http://developer.android.com/reference/android/location/Crit... I really would like to know if you think that Apple's documentation is poor or if you are just trolling because the facts of the situation don't support your argument. Which part of the documentation is "quite flawed" like you originally claim?
rimantas 16y ago
Garbage collection on OS X appeared in Leopard with Objective-C 2.0—later than iPhone, but before iPhone SDK. Older models are still around and even iPad has less memory than iPhone 4 so it is not unreasonable to treat it as resource too precious to be left ar the mercy of GC. On the other hand, manual management is not that complicated and does not add much overhead in programming except the initial phase of getting used to it.
- rbritton 16y ago
  If they do ever introduce it, I sincerely hope it is completely optional. On my iPad app, I run with such tight memory constraints while dealing with large image files that it has to be freed up when I tell it to or I'm likely to get killed by the memory watchdog.
  - protomyth 16y ago
    I would expect it would be if they follow the pattern from OS X. I do wonder what the breakdown in new OS X apps between GC and retain/release.
  - chunkbot 16y ago
    The existence of a garbage collector doesn't mean that the programmer has to play a totally hands-off role in the allocation of objects; as with any coding, there are usually a few bottlenecks that deserve special care. A system with a good GC will provide opportunities to tune; for example, to make hints to the GC about lifetime and locality and so on. http://www.jwz.org/doc/gc.html http://www.jwz.org/doc/gc.html
- chc 16y ago
  Older iPhone models cannot run the current OS anyway. And manual memory management is not a showstopper, but to say it's "not that complicated and does not add much overhead" is just wrong. It's conceptually simple, but the devil is in the details. I would bet that if you took a poll of all Cocoa programmers who have been working in the field since — well, pick any date you think qualifies as "out of the initial phase" — and ask them how many of their programs have done correct memory management without debugging, you will get an answer of 0.
rgbrgb 16y ago
Agreed. I had the exact opposite reaction when I started doing some Android dev after coming from iPhone. I find Xcode to be at least 80,000 times better than Eclipse (memory usage, UI, interface builder, speed, general bugginess). I also REALLY like Apple's docs and the ease of integrating C code (no NDK!) when you need to do something like real-time audio. My only really big complaint is the certificate signing process which can be a real pain. I mean, I can totally see why Android might feel better or more familiar to a Java programmer though.
- jamesg 16y ago
  I'll make just one refutation to this: I am not a Java programmer :) I had to learn Java specifically for this project. Python is my preferred hammer for most nails, but not an option on mobile. I've also been a professional C programmer before, wreaking havoc in the kernel. I've got opinions on Objective-C, but that's a subject that deserves a whole separate post.
- BenoitEssiambre 16y ago
  I have a question. I asked this to a few mac users and haven't received a good answer. How the hell do you get xcode (or other programs, but xcode is particularly bad) not to end up being a big piles of small windows you can't access effectively because they don't have a dock icon? The only way I found, was to long-click on the xcode dock icon which after a while splatters small versions of the windows everywhere, then scan these tiled windows until I find the right one and click on it. I have to do that atrociously long multi-step process every damn time I wan't to take a glance at another window! This, for example, makes the internal iOS documentation useless to me. At least I can use the web documentation to get the browser dock icon but when I don't have an internet connection I'm out of luck. While I'm at it, is there any way, when using 'Spaces' to do a desktop change in one click? I'm mainly a Linux user and I'm used to having multiple desktops. OSX also has this functionality, and the 'Spaces' icon actually has four little square on it that represents the four desktops it's controlling. However when I click on one of the small squares, instead of going to the right desktop like it does in Gnome/Linux (and has been doing right since about 1995), it goes into an animation where the four desktop are displayed tiled full screen and I have to pick one. That is a two step process with an animation in between for something that should clearly be instantaneous. Is there an alternative to this. Both these things are driving me insane! Like in the article, I bought a mac just to do iOS development and up to now my experience on osx felt like using a broken out of date gnome desktop with serious usability issues.
elai 16y ago
There are some things that are in the private apis that make dealing with certain problems a 100 times easier. Sometimes you just want the gui to force a rotation to a certain orientation at some point of the app. Other public api's such as rotate top bar are more crufty, and don't work 100% of the time, or require fragile workaround where you do all the rotation manually yourself because the public apis are fragile, while the one-line simple private api would of done the trick.

mickdj 16y ago

Clarification: We don't use any private API's on iOS, James' comments were with respect to what we do with location and networking. Apple's documentation is great for most visual elements, but CLLocation* in particular has quite flawed documentation.

pkaler 16y ago
Where are the flaws in CoreLocation or the documentation? CLLocationManager is instantiated like any other NSObject. CLLocationManagerDelegate returns asynchronous results like any other protocol in Cocoa/CocoaTouch. CLLocation, CLHeading, CLRegion are about as close as you're going to get to get to C-style POD structs in Objective-C. The documentation is all here and the API is about straight forward as it is going to get. http://developer.apple.com/library/ios/#documentation/CoreLocation/Reference/CoreLocation_Framework/_index.html http://developer.apple.com/library/ios/#documentation/CoreLo...
- mickdj 16y ago
  I don't want to veer O/T, but that's not the hard stuff in CLLocation. There's a lot that could be discussed, but as one example: optimizing for battery conservation requires knowing which radios are currently powered up. iOS makes its own decision as to which of the 3 styles of location service to engage, based on the desiredAccuracy and distanceFilter values. However the WiFi/GPS radio have different costs for runtime and warmup, so this API doesn't help when you are attempting to optimize for all 3 of: Accuracy, Timeliness, Battery conservation Furthermore, the accessible battery percentage in UIDevice.batteryLevel is only reported to the nearest 5%, which is not granular enough to be of use in real-time server-based tweaking.
  - pkaler 16y ago
    There's a lot that could be discussed... There isn't a whole lot to be discussed. iOS minimizes battery usage based on how close cell towers are, type of cell tower, altitude, Wifi spots database, state of GPS almanac, hardware/driver combination, etc like a any good OS/kernel (including Android) should. The App sets CLLocationAccuracy to kCLLocationAccuracyBest, kCLLocationAccuracyNearestTenMeters, kCLLocationAccuracyHundredMeters, kCLLocationAccuracyKilometer, or kCLLocationAccuracyThreeKilometers and that's it. The OS will almost always be able to minimize battery usage because it has way more information than the App could or should ever have. The App will never be able to optimize this setting because there will always be new hardware with new tradeoffs. Your claim is that Apple's documentation does not describe the implications of the laws of physics for an arbitrary location that the user may reside at and does not reveal implementation details of the kernel that change every hardware/software revision. The API could not be much simpler or much better documented. Do you really think that Android's documentation is better? http://developer.android.com/guide/topics/location/obtaining-user-location.html http://developer.android.com/guide/topics/location/obtaining... http://developer.android.com/reference/android/location/package-summary.html http://developer.android.com/reference/android/location/pack... Because the Criteria class on Android is essentially the same as CLLocationAccuracy. http://developer.android.com/reference/android/location/Criteria.html http://developer.android.com/reference/android/location/Crit... I really would like to know if you think that Apple's documentation is poor or if you are just trolling because the facts of the situation don't support your argument. Which part of the documentation is "quite flawed" like you originally claim?

rimantas 16y ago

Garbage collection on OS X appeared in Leopard with Objective-C 2.0—later than iPhone, but before iPhone SDK. Older models are still around and even iPad has less memory than iPhone 4 so it is not unreasonable to treat it as resource too precious to be left ar the mercy of GC. On the other hand, manual management is not that complicated and does not add much overhead in programming except the initial phase of getting used to it.

rbritton 16y ago
If they do ever introduce it, I sincerely hope it is completely optional. On my iPad app, I run with such tight memory constraints while dealing with large image files that it has to be freed up when I tell it to or I'm likely to get killed by the memory watchdog.
- protomyth 16y ago
  I would expect it would be if they follow the pattern from OS X. I do wonder what the breakdown in new OS X apps between GC and retain/release.
- chunkbot 16y ago
  The existence of a garbage collector doesn't mean that the programmer has to play a totally hands-off role in the allocation of objects; as with any coding, there are usually a few bottlenecks that deserve special care. A system with a good GC will provide opportunities to tune; for example, to make hints to the GC about lifetime and locality and so on. http://www.jwz.org/doc/gc.html http://www.jwz.org/doc/gc.html
chc 16y ago
Older iPhone models cannot run the current OS anyway. And manual memory management is not a showstopper, but to say it's "not that complicated and does not add much overhead" is just wrong. It's conceptually simple, but the devil is in the details. I would bet that if you took a poll of all Cocoa programmers who have been working in the field since — well, pick any date you think qualifies as "out of the initial phase" — and ask them how many of their programs have done correct memory management without debugging, you will get an answer of 0.

rgbrgb 16y ago

Agreed. I had the exact opposite reaction when I started doing some Android dev after coming from iPhone. I find Xcode to be at least 80,000 times better than Eclipse (memory usage, UI, interface builder, speed, general bugginess). I also REALLY like Apple's docs and the ease of integrating C code (no NDK!) when you need to do something like real-time audio. My only really big complaint is the certificate signing process which can be a real pain. I mean, I can totally see why Android might feel better or more familiar to a Java programmer though.

jamesg 16y ago
I'll make just one refutation to this: I am not a Java programmer :) I had to learn Java specifically for this project. Python is my preferred hammer for most nails, but not an option on mobile. I've also been a professional C programmer before, wreaking havoc in the kernel. I've got opinions on Objective-C, but that's a subject that deserves a whole separate post.
BenoitEssiambre 16y ago
I have a question. I asked this to a few mac users and haven't received a good answer. How the hell do you get xcode (or other programs, but xcode is particularly bad) not to end up being a big piles of small windows you can't access effectively because they don't have a dock icon? The only way I found, was to long-click on the xcode dock icon which after a while splatters small versions of the windows everywhere, then scan these tiled windows until I find the right one and click on it. I have to do that atrociously long multi-step process every damn time I wan't to take a glance at another window! This, for example, makes the internal iOS documentation useless to me. At least I can use the web documentation to get the browser dock icon but when I don't have an internet connection I'm out of luck. While I'm at it, is there any way, when using 'Spaces' to do a desktop change in one click? I'm mainly a Linux user and I'm used to having multiple desktops. OSX also has this functionality, and the 'Spaces' icon actually has four little square on it that represents the four desktops it's controlling. However when I click on one of the small squares, instead of going to the right desktop like it does in Gnome/Linux (and has been doing right since about 1995), it goes into an animation where the four desktop are displayed tiled full screen and I have to pick one. That is a two step process with an animation in between for something that should clearly be instantaneous. Is there an alternative to this. Both these things are driving me insane! Like in the article, I bought a mac just to do iOS development and up to now my experience on osx felt like using a broken out of date gnome desktop with serious usability issues.

elai 16y ago

There are some things that are in the private apis that make dealing with certain problems a 100 times easier. Sometimes you just want the gui to force a rotation to a certain orientation at some point of the app. Other public api's such as rotate top bar are more crufty, and don't work 100% of the time, or require fragile workaround where you do all the rotation manually yourself because the public apis are fragile, while the one-line simple private api would of done the trick.