I am working on a consulting gig in which my client got a prototype for his App to work on Mac OS X 10.10 (Yosemite) by using a storyboard. However the App crashes on 10.9.x and earlier, because the APIs required to use storyboards in Cocoa desktop applications were not yet available.
At present the application is not very complex, so I could satisfy his immediate requirement by revising his application so as not to use storyboards at all, I would instead implement his UI "The Old-Fashioned Way", without using storyboards at all.
I'm not real sure what is the best course of action. If I implement what I just said, he will eventually find his UI deprecated by Apple. If I use a storyboard for 10.10 and later, but not on 10.9 and earlier then there could be twice as much work for my client to develop this code.
Note that, as a consultant, I could stand to gain by increasing my client's workload. I don't want to do that as I regard it as unethical to take advantage of my clients by writing bad code. I really want to do right by this fellow.
Right. Storyboards are only available in MacOS X from 10.10 (Yosemite) onward. Support for storyboards is feature of the Cocoa framework, so the fact that it doesn't exist on versions <= 10.9 means code using storyboards won't work.
I'm not real sure what is the best course of action.
I think the most reasonable solution is to explain the situation to your client and let him decide. It's going to be a long time before .xib-based code goes away, if it ever happens, so sticking to .xib files for now is not necessarily a bad choice. On the other hand, your client might prefer to have the most forward looking app you can build, and he may not care all that much about supporting older OS versions. (Several sources indicate that as of early 2015, about half of all Macs are running Yosemite.) You'll serve your client best by giving him the information he needs to make a decision and then writing the app in accordance with his wishes.
Related
Mavericks is coming out and for developers that's always a busy time with all these new features and APIs to know about and use. For me, I think it is the perfect time to ask a question that has been bugging me for a very long time.
Here's the thing, in context: I am developing an app that I want to be able to run on 10.8 (so the target system is 10.8+). Right now I am using the 10.8 SDK. However, with the release of 10.9 comes some pretty sweet APIs that I would like to use in my app. I use them in my code, but then, of course, I have to compile my app against the 10.9 SDK. If I do that, can I still run the app on 10.8?
Or, in a more general way, if I compile my app against one SDK, can I still run it on a 'lower' Mac OS? If yes, can you explain how does it work under the hood (what is the compiler doing)? This is a mistery for me.
Generally speaking, Xcode disassociates the issue of the SDK and the Deployment Target of the app.
The SDK is determined by Base SDK, and the deployment target is determined by OS X Deployment Target. These both show up in the Build Settings tab for each target in Xcode.
When programming with different SDK and Target, you are responsible for making sure that you don't call methods or functions on an OS that doesn't have them. This is often facilitated by weak linking (in the case of new frameworks) and/or using -respondsToSelector: in the case of new methods on existing classes and frameworks.
In Xcode, under build settings, there is an option for target OS where you can pick 10.8. 10.8 applications are generally compatible with 10.9 so the compiled application will work with both OSs.
Don't expect the new Apis to work when running on a lower version. It doesn't work that way.
There are two choices (or at least I know two) for implementing XPC client and service for Mac. NSXPCConnection which is introduced in 10.8 and XPCKit. What should I use to implement helper app that resides in menu bar and uses XPC to read data from the main app.
The main difference I see is that XPCKit will work in 10.7 Lion while NSXPCConnection is available only in 10.8 Mountain Lion. What else should I take into consideration when choosing between them. I'd be grateful for the responses from the developers who used both.
P.S. My app still works in 10.7, however from my previous experience it's not a problem to require the latest version of OS X in 2-3 months after release.
Finally I decided to use NSXPCConnection.
It is provided by Apple, so, less chances to have problems with updates.
Since the release of Mountain Lion and NSXPCConnection it seems that XPCKit is not supported any more.
I've tried both and for me personally NSXPCConnection seems to be a better solution
I want to update my developing knowledge from iOS to Mac for distributing my apps to Mac App Store.
What are the differences? What are the limitations?
For example, if I want to port my iPhone app that syncs contacts with social network the various NSRequest or ABAddressBook are the same? It changes only views and corresponding view controllers?
Does exists some sort of "adapters" from iOS to Mac to easily convert iOS apps to Mac?
In general, what challenges Mac apps arise respect to iOS apps?
Thanks
If you've gathered some experience you will get along with mac development in no time. Mac and iOS have many things in common, however there are some gotchas, not all of which are visible at first glance.
The most obvious difference may be the use of viewcontrollers - cocoa for mac knows viewcontrollers, however they play a different (and less important) role.
I think the best approach for you would be to take a quick look at the Cocoa Application Tutorial and the Cocoa Fundamentals Guide. Most of it will appear familiar to you. Other than that I'd suggest to not port that project over, but use it as a opportunity to learn mac dev and recreate it from scratch (if it is not too complex). Of course you can copy paste many of the logic stuff, no need to reinvent the wheel.
By the way, I started out developing for iOS too and I found it to be very easy to get used to cocoa mac.
As to your question regarding NSURLRequest (I think that's what you meant, theres no NSRequest in either platform), they are almost the same. Just look it up in the reference library. I found it very helpful to have the iOS and mac os reference library available at the same in my browser, so I could look up differences quickly.
In the wikipedia article on Cocoa it says:
There are also open source implementations of major parts of the Cocoa framework that allows cross-platform (including Microsoft Windows) Cocoa application development, such as GNUstep, Cappuccino, and Cocotron.
Yet when I looked into whether Mac application Tweetie was available for windows the developer had ruled it out:
Windows doesn't have Cocoa, the programming environment that Tweetie is made in, as such, it seems like a poor possibility.
I'd like to have an answer to point the Tweetie developers (and as a resource for other cocoa developers) which would tell them:
Which implementation is the most suitable for getting a cocoa app running on windows?
How much work is it likely to take to get the app running under windows?
How easy/hard is it to maintain a common code base for Mac and Windows?
(any other considerations I've missed?)
Of course if it would be too much work I'd like to know that too before suggesting it and potentially sending someone else on a fruitless search.
Don't forget:
“Major parts of the Cocoa frameworks” is not the same as “the entirety of the Cocoa frameworks”. Tweetie could be using something that's missing.
Tweetie could be (very probably is) using APIs from the non-Cocoa frameworks, such as Core Foundation, Core Services, Core Graphics, and Core Animation. A port of the Cocoa frameworks alone won't include any of these APIs, and even a more complete Mac-API-emulation framework will not include all of them.
These frameworks are eternally chasing Apple. Even if they catch up, they'll be instantly behind again as of the next Mac OS X release. Mac developers already put off using new APIs in new Mac OS X releases while they wait for users to upgrade to those new releases; now you're asking atebits to also wait for the other-framework developer to catch up to Apple again.
Any second implementation of an existing API will have bugs that the first implementation doesn't, and vice versa. These differences will cause development and support problems.
You're asking atebits to add a third platform to an application that already exists on two. Supporting one platform is a lot of work. Supporting two platforms is a hell of a lot of work. Supporting three? Now you're getting into big-company territory.
So, even with these Cocoa-like frameworks, the answer is: Hard.
Among GNUstep, Cappuccino and Cocotron, Cocotron is only possible choice to port a Mac application to windows.
Cappuccino is for web and GNUstep only runs on top of cygwin or mingw, which means the GUI looks nothing like native windows apps.
It is theoretically possible to build cocoa windows apps using Cocotron. However, the reality is that it is still very hard to use, and it is still quite limited in the Cocoa API.
Therefore, two possible solutions:
Try hard to remove the codes that are not supported by Cocotron in the original code base and do the cross compilation. Maintaining common code base will be painful.
Start a new GUI at all, no common code base. two choices here
Start a cross platform project with cross application framework such as Qt, or Java.
Start a windows only project. There are a lot of choices here, .Net WinForm application, MFC, etc.
There are Windows compilers for Objective-C (the programming language used to write cocoa apps). However, Cocoa includes the frameworks for presenting the GUI. These visual frameworks are specific to Mac OS X because they use OS X only windows and other controls. So someone would need to re-implement the controls in Cocoa to use Windows controls.
Also, I am fairly certain that Tweetie uses Mac OS X only technologies like Core Animation. This does not exist on Windows, so the nice animation effects present in the apps would have to be implemented in a completely different way.
My company is in the process of rewriting our software from scratch, and I'm the one who is going to be doing most of the work in rewriting the Mac client (The core of our software is Windows based, and the Mac client communicates with it through a webservice).
This isn't a real heavy app, mainly does some background work tracking stuff and a UI component for the user to enter information.
I'm trying to decide how hard I should argue for dropping support for 10.4 and going with pure 10.5+/Obj-C 2.0 code.
My main motivations for this are:
It would be easier to code, I could use all the features of Obj-C 2.0 such as synthesized properties and fast enumeration.
It would give me access to several classes, and methods in existing classes, that don't exist in 10.4 (Just in mocking up a UI I've come across NSPathControl and NSTreeNode, both of which I would otherwise be very happy to use.
Preparing for the conversion to 64 bit coming in Snow Leopard. It seems like most of the techniques for preparing for the move to 64 bit (NSInteger, etc) are only available in 10.5+, and it would not be possible to use these if writing for 10.4.
The downside would of course be that we'd no longer be supporting an operating system that was only a year out of date.
My boss is himself supportive of this move, but of course has our customers to consider and doesn't want to cause any more issues for them than are justified. The director of support would like to support 10.4. I suspect the other execs will be marginally against it at first, just due to the not being able to support some customers thing. Everybody would be open to persuasion by a good argument from either side.
I'm trying to talk to some of the support people and get an idea of how many of our customers are actually still using 10.4, but I don't have that data yet.
Some kind of hybrid solution might be possible, such as rewriting parts of the old client to use the new webservice, or writing the client in 10.5 and backporting it to 10.4 if enough people made a fuss, but quite frankly those sound like they're likely to be even more trouble than giving up the 10.5 features and writing the code in 10.4 to begin with.
So I guess my questions are as follows:
Given the information above, do you think making a case for the adoption of 10.5+ only is the right thing to do? Do you have any suggestions as to how this might be presented positively to the rest of the company?
I don't know as much about the coming 64 bit transition as I'd like. Does anybody have any good references on what will be different, and do you think that supporting only 10.5+ would make this transition easier for us?
If it were I doing the update, I would target 10.5, especially since 10.6 is just around the corner and 10.5 did come out with a lot of great, new things (especially Objective-c 2.0). However, I think you really need to answer this question based on what you think your target customer group will be using. If they are slow to adopt new technology, it may be that you have to support 10.4 or risk losing a portion of your customer base.
On the other hand, you can actually target 10.4 and write using the 10.5 SDK. That way you can take advantage of all the preparations for 64-bit added to the SDK. You just have to ensure that you don't use any classes or features of the frameworks that didn't exist in 10.4. You can also do weak linking to the 10.5 frameworks and programatically decide whether you can use a new feature or not (while this is a bit of extra work up front, you can easily phase 10.4 support out of your code in the future and take full advantage of 10.5 improvements for users that actually are running 10.5).
There are a lot of blogs and write-ups about doing the cross-platform stuff out on the web. The other thing to keep in mind is that if you do target 10.4 make sure you have a 10.4 machine available to do a lot of testing (especially if you compile from the 10.5 SDK to take advantage of the 64-bit ready features). Also check the docks for any feature you may want to use from the 10.5 SDK. Many features were actually available in 10.4 but undocumented and the new documentation usually states which features you can safely use when deploying to 10.4
Do you need 64-bit? Unless your application is very CPU-intensive, it won't make any difference.
Tiger can run 64-bit applications, but without GUI. If you need 64-bit, you can create 64-bit CLI executable that does heavy lifting and provide 32-bit font-end for it (using NSTask and NSPipe).
You can also have separate .nib files for Leopard and Tiger:
-(id)init
{
BOOL tiger = floor(NSAppKitVersionNumber) <= NSAppKitVersionNumber10_4;
NSString nibname = (tiger ? #"WindowTiger" : #"WindowLeopard");
if (self = [super initWithWindowNibName:nibname])
…
You really need to find out what your customers are using, and the support person is probably best positioned to know, or the product manager. That said there's nothing wrong with making the technical arguments clear now even if 90%+ of your user base were pre-Leopard; that way the issues will be known (and hopefully understood) so you'll have more support as the environment does change.
I never wrote production code in Objective-C and its hard to keep up, but as far as i am aware NSInteger and friends are in 10.4, it's just that Cocoa isn't 64 bit in 10.4 whereas in 10.5 most of it is (so no more need for seperate 64bit worker process under a 32bit UI).
I don't know what your product is, or who your customers are, but from my experience, Mac users are early adopters (relatively speaking) I've never used an OS X version longer than two weeks before the next upgrade was out, and in my circle I am a late adopter. Ofcourse I'm not just a business Mac user and that may well make a big difference.
What makes 64bits a requirement in your code? There's not much of a reason to not compile a universal binary holding as many architectures as you wish you could have one binary run on G4, G5, IA32 and IA64 no problem, and have it be native on all of them. If you're just doing 64bits because you can there's no reason (that I can imagine) not to keep supporting 32bits, but if you want stuff like CoreAnimation you don't have much choice.
I don't think it's wrong to demand 10.5 for new development, but it wouldn't make much business sense to force a whole new OS on customers just to keep using your existing product. So if you can, stay compatible, maybe backport your new features/patches for a time. There is a good reason for forking in version control and this might be it.
edit-
Since I posted this I learned that I was wrong and NSInteger did not exist before 10.5. I think I assumed too much having used similar types (like NSDecimal) earlier.