I've asked a more specific question over here but it's rolling amongst tumbleweeds.
Maybe I can get an answer to a more general question:
Carbon being deprecated and 32-bit–only, how bad of an idea is it to call Carbon APIs in an otherwise fully 64-bit, modern Cocoa app?
Will it negate whatever improvements 64-bit execution brings?
Could it jeoprardize the MAS review process and contribute to an app getting rejected from the Mac App Store?
I understand that you should probably not choose to do it, I'm talking about a situation where import Carbon is the only way to achieve something. Is the feature still worth it at that point?
You simply can't call Carbon functions from a 64-bit app. The link will fail (if the compile didn't already fail). At best you could put the Carbon stuff in a helper tool that you talk to with a pipe or something. And yes, Apple has said that using deprecated APIs can result in your app being rejected by the Mac App Store.
Related
The last days I sent a new build of my app to Apple to fix some minor bugs with macOS Catalina. This evening Apple called me and explained that they are refusing the new version in the AppStore because the application monitors keystrokes. I use the Clipy/Magnet library (github.com/Clipy/Magnet) to manage the hotkeys. This library uses a Carbon API. Admittedly, I'm a little surprised - on the one hand that Apple is calling me directly via phone about this and on the other hand the use of this library has not caused any problems so far. The only thing I noticed about the new build was that Catalina asks for "Input-Monitoring" at the first start of the program. I've installed several other programs that also respond to global hotkeys and none of them require the permission for "input monitoring".
Does anyone have a similar phenomenon under Catalina or how do you solve the problem of query/monitoring global hotkeys?
I know of numerous applications using the MASShortcut framework, and I don't believe they've had issues with the store. It also uses a carbon API, but I think the issue in Magnet is the call to CGEvent.tapCreate which can globally monitor all keyboard input, and which MASShortcut doesn't use.
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.
Apple has killed Carbon for 64 bit applications. I've got a pile of legacy code that targets carbon UI widgets that I'd like to keep alive for a while. Most of it is in the form of plugins and bundles that will have to go 64-bit in sync with their host platform.
The choice that Apple seems to be assuming is to throw all the legacy code away
and rewrite using Cocoa. It's not going to happen in the short run, if only because
the same legacy code is tied to a PC binding as well.
I'm considering 3 Options
(1) Dive into cocoa, create a compatibility package that supports the small subset
of carbon that I actually need.
(2) use Cocoatron as the new target. In the short run bridge carbon-to-cocotron, and maybe in the longer run convert to cocoatron native for both mac and pc. (ref: http://cocotron.org/)
(3) use QT as the new target. See option (2). (ref: http://qt.nokia.com/)
What I would really prefer is a fourth option, such as a bootleg copy of the 64 bit
Carbon beta that Apple killed, or a compatibility package explicitly intended just
to emulate carbon.
I would recommend you choose option 1. Creating a Cocoa UI wrapper for your code will likely not be as complex as you think. A common way to create a cross-platform app is to create the bulk of the app in cross-platform C++ and use Cocoa/Objective-C++ for the Mac UI and one of the Windows APIs for the Windows UI.
This option also has the advantage that it is fully supported by Apple and the APIs are stable and mature.
Cocotron is a nice idea but as of now it's not mature enough (in my opinion) to provide a robust cross-platform solution. I know there are successes with it but the sample size is small.
Qt is an option. However, it suffers from a very un-Mac-like UI. Using a Qt app on the Mac always feels like a quick port rather than a native app, and this is unlikely to ever change.
The "bootleg Carbon runtime" is just a fantasy, there is simply no way to get that working reliably and absolutely no chance to distribute it. You will need to find another way.
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.
Background: This is for a university managed lab environment. Upper management wants to know how often users are using the various software we purchase for the labs. I've already implemented a solution for our Windows machines which consists of a client that tracks user process invocation and sends the results to a web service.
Now I need to create an equivalent Mac client but I have zero experience developing for the Mac platform and its various APIs. Our Macs are currently running 10.4, but will eventually be moving to 10.6 within the next year. I think I've got a handle on consuming the web service using something like gSOAP or even Mono. For the process tracking, I was looking at the Carbon Event Manager. But I've been reading that the Carbon APIs are on the road to being deprecated and I'd rather find something that will be supported moving forward.
Should I just use the Carbon stuff for as long as it works? Or is there some equivalent library I could be using that won't be phased out anytime soon?
Carbon APIs are not being deprecated, Carbon applications are. Feel free to use the event manager.
See The myth of Carbon’s 64-bit unavailability