When I was a beta tester for Bill Gates(a windows user),I used to use a book by a guy called Dan Appleman that described most of the WINAPI calls. Is there a definitive source for the OSX API? Over the years Apple’s operating systems have had many API sets that it is difficult to work out which one is the definitive one to use.
Has both Swift and Objective-C
-
Mac Developer Library
https://developer.apple.com/library/mac/navigation/ -
Download Documentation with Xcode
Xcode->Preferences->Downloads->Documentation (OSX and iOS) -
Use Dash to load and access documentation sets
http://kapeli.com/dash
Well, those Appleman days (I had the book, it was glorious) are over. Back then books were viable because the product cycle lifetime permitted it. Nowadays, no one prints anything -the book would be out of date almost immediately.
But, one wonders why an OSX Appleman couldn’t arise and write stuff on the web, but again the problem because the lack of compensation, and no one will do anything unless they are paid. We are reaping what we sow.
The suggestions above are good, but they are hardly written in “english”, where things are explained a bit beyond the facts. Just like Appleman did. Each API function was not only written in VisualBasic terms, but Appleman did a lot of explaining HOW and WHY it worked. It was really wonderful.
To this day, Microsoft documentation on Msdn is somewhat friendlier, if not as beautiful as I remember Appleman’s book. It may be due to the use of C# to describe the calls, which is by far easier than awfully abstruse Objective-C in the Apple Developer Library.
Luckily, now the calls that are not deprecated are also described in Swift, and that is a much more humane language 
Yes, and the very reason I was able to make VB do what I wanted. Given the style of writing and to attention to detail, it is not too hard to think of his book(s) as the first “Win API for Dummies”
While on the subject, is there any way to gauge the lifecycle of any API call regardless of platform? Obviously trends in hardware are going to greatly affect the depreciation schedule of any call, but it would be nice to think that some fancy call you have used in your killer app is not going cause a crash and burn in the next year or so.
[quote=140761:@chris benton]@Michel Bujardet Luckily, now the calls that are not deprecated are also described in Swift, and that is a much more humane language
While on the subject, is there any way to gauge the lifecycle of any API call regardless of platform? Obviously trends in hardware are going to greatly affect the depreciation schedule of any call, but it would be nice to think that some fancy call you have used in your killer app is not going cause a crash and burn in the next year or so.[/quote]
Here, let me say right away that if you plan on developing for Mac, you better brace for unpredictable surprises and rocky transitions. I am precisely in the process of revising code created back in 2013, and dang! Yosemite has deprecated one of the calls that I thought would hold for a while.
Sam Rowlands, who is a master at using the API, is losing hair over Yosemite, as he is trying to keep up with things that worked in early betas of 10.10 that now stopped working in the final version.
What you learned with Appleman’s book is still readily applicable in Xojo Windows today. Windows 10 still perfectly supports Win32 API calls. Yosemite now stops working with some 32 bit calls with absolutely no warning, and no mention of deprecation in Apple Developer Library as well.
Apple suddenly announced a couple weeks ago that starting February 1st, 2015, all iOS apps will have to support 64 bits. One can legitimately fear the same kind of diktat one of these days for Mac OS X, especially since Mac OS X has been 64 bits since Mountain Lion.
The very word “depreciation schedule” sounds strange in the Apple Universe, where things usually come from the blue with no warning whatsoever.
I guess it is a question of philosophy. Microsoft has erected backward compatibility as a quasi religion. Apple on the contrary tends to link the destiny of software to its hardware. Which makes sense, since it is, primarily, a hardware company. All is not bad in that, though. In the Windows universe, people may still use a version of Photoshop from the 90’s and not think much of it In the Apple world, there were at least 5 different versions since then that users had to upgrade to. For software developers, although hellish, this situation favors higher and more frequent levels of upgrade. In other words, it is good for business.
When all of those PC to Mac convertees out there do their best to shout down all of those ‘retards’ still using Windows, I guess not much thought is given to the view of a software developer. If as you say (Michel) things are very fluid in the fruit world and what you create today maybe tomorrows “Please explain” email, It is very hard to hang your hat on API continuity. I can’t imagine what frustrations the Xojo engineers must go through given that a language feature may be depreciated even before the next update.
It would be nice to think that the fruit people would send out a nice email beforehand warning developers that API X,Y, and Z will no longer be available in 6 months time due to blah, blah, blah, but that may be an over verbose display of respect and consideration.
[quote=140913:@chris benton]When all of those PC to Mac convertees out there do their best to shout down all of those ‘retards’ still using Windows, I guess not much thought is given to the view of a software developer. If as you say (Michel) things are very fluid in the fruit world and what you create today maybe tomorrows “Please explain” email, It is very hard to hang your hat on API continuity. I can’t imagine what frustrations the Xojo engineers must go through given that a language feature may be depreciated even before the next update.
It would be nice to think that the fruit people would send out a nice email beforehand warning developers that API X,Y, and Z will no longer be available in 6 months time due to blah, blah, blah, but that may be an over verbose display of respect and consideration.[/quote]
MS and Apple are worlds apart when it comes to developer relations.
Some of it is the companies histories - MS has always made a big deal out of backwards compatibility so devs would write code & it would just continue to run forever. But thats a double edged sword - it means devs DON’T have to update if they don’t feel like it. That’s great for consumers since they buy your app once & use it for the next 10 - 15 + years.
And for MS once they’ve made this pledge its hard to push (literally push) devs to adopt new technologies rapidly so they can leave old possibly insecure APIs behind. That VB6 apps still lean for as long as they did was a testament to backwards compatibility. And consumers know this exists so they too don’t update as often and put not pressure on devs to keep up.
For good or for bad thats what it is there.
Apple doesn’t make that same level of commitment & much more aggressively drops old API’s - for good or for bad.
They do tend to push much harder to get consumers to update - and the adoption rates they have for new versions of the OS is a testament to how successful they are & how well that works. So devs are forced to keep up because consumers DO move.
Apple does often say “Hey you should be adopting X” fairly far in advance. But they’ve also been known to say nothing and just change the rules.
Quicktime anyone ? - They did say “You should be moving to AVFoundation” quite a long time before but NEVER said “Do it now because we’re killing quicktime in december” or, like the recent “iOS Apps have to have 64 bit support” which is something they encouraged but never said anything about devs MUST do it until they made it public.
Again this is the reality in this side of the OS world.
IMHO - Apple could really learn something from MS on the dev relations front
That said Apple usually creates “private api’s” until such time as they are happy with things & its settled down and stable.
Then they make them “public” and I can’t recall the last time I saw them do this & drop it in the next release or two.
That doesn’t happen very often.
OS X is built on what used to be NeXTStep & there are many many API’s from 15 + years ago that still exist & are stable.
Let us be fair : deprecation is here to say “please don’t use this as it will sometime in the future cease to work”. So using deprecated things also implies “at your own risk”.
The issue here is that they do not give precise cut off time. But they do give warning.
The Carbon thing is a good example. While Windows was using Win32, Apple was using Carbon. We are talking 2000. Both platforms are still compatible with the current OS version, respectively Yosemite and Windows 10. But Carbon was officially deprecated on July 24, 2012. To be perfectly clear, any developer who decided to ignore the deprecation for whatever reason between laziness, irrational fear and reverence for the good’ol things knows the writing is on the wall. Now when eventually a new system will come that drops Carbon compatibility, I hear in advance the tears and moaning of the inconsequents. My apps have been entirely Cocoa since 2013, thanks to Xojo who had long before offered Cocoa. Sure, that required adjustment. But much less drama than having to do that in emergency.
I cannot help but to compare that with the retirement of XP. Sales ended back in 2010. Yet, the same kind of procrastinators, in general with all sorts of excuses and opinions, decided not to care and to go on with unchanged software. Then five years later, which in computing time is equivalent to half a century, Microsoft retires XP for good with the end of support early this year. And there are people screaming and yelling they don’t like the new and will enter resistance.
As I said, Apple change is good for business. Forcing customers to upgrade creates more sales for developers. How can it be a bad thing ?
I is exhausted bruh! These last few years I’ve spent so much time keeping up with Apple.
- App Sandbox
- Retina
- Changes to code signing rules.
- more changes to code singing rules.
- Preparing apps for Yosie.
- further code singing changes.
- freaking out when 32-Bit libraries disappear.
- other issues with Yosie…
It’s true however that people are begging me for Yosie compatible versions of our apps (that are not already Yosie compatible).
I just don’t have the heart to charge people just to get a Yosie compatible version. I hated that Photoshop (which is the only time I would update).
Back to the days I was working at Apple France.
Apple USA issued in the early 1992 (I think it was 1992) a statement about FP units presence in 680x0 processors that said something like: do not believe there will always be a fpUnit in 680x0 processors.
In Mid-October 1992, we released Macintosh LC with a 68LC020 WITHOUT FP Unit. Who have their software broken ? Word, Excel, etc
So, sometimes, after preaching in the desert, one can start to stop doing work in vain !
You don’t have to charge full price. I am sure people will understand. I was a victim of the Intel transition like many and hated having to repurchase. Actually, that is when I stopped using Office altogether. If they had offered a decent upgrade, I would have stayed with them.
Fact remains that Apple sells tons more software per machine than Windows, thanks to their constant evolution.