I have an old mac OS application developed in Mojave with the deployment target 10.12. Now how to update mac OS application to support Catalina? Or is the application automatically supports all future mac OS versions?
When developing for macOS (or any other Apple platform, for that matter), there are two key concepts to take into account when thinking about compatibility:
The SDK version: this is the SDK you're compiling against and it is usually determined by the Xcode version you're using to build your project.
The Deployment Target: this is the lowest OS version you want to support.
Normally, if you have followed the best practice in implementing your code and all of your dependencies have done the same, updating an app for a new macOS version requires only to download the latest Xcode on the latest macOS, build it and run your smoke tests (manually or through automated tests).
There may be things that have been deprecated in the meantime and Xcode will report them as warnings while building. You may read more about deprecated APIs in the macOS 10.15 release notes.
Keep in mind that you don't actually have to rebuild your app every time a new macOS version comes out. Even though it is better to test it at least once and dedicate time to explore and make use of new APIs, apps built on the previous version of macOS will, most of the times, run flawlessly on the next version (and maybe even further). This obviously depends on the app complexity, so your mileage may vary.
Related
I want to run IOS Simulator on Windows 10.
Is there a way to do this?
I dont think its possible to get the iOS simulator working on Windows. But if you are willing to explore a dual boot setup, have patience (and a supported motherboard/processor), then you could use OpenCore or Clover to get a macOS running on your pc. This will give you access to the iOS simulator and the other xcode tools.
If you take this route then you should know that macOS doesnt support ntfs writes out the box. This means that if you decide to create a shared volume that both the mac and windows partition would read and write from, then you would either need a 3rd party ntfs drive (e.g. macfuse) or to format your volume to exFAT (this gave me the best results and was free)
If you intend to run the latest macOS I would recommend going with OpenCore. The latest Clover versions ports pieces of OpenCore to it, and finding documentation on configuring the new Clover was a hassle for me. If you are fine with running Catalina and using an older xcode (and thus older iOS simulator), then I would recommend giving tonymac tools a shot. Building the installer took with very little effort. You need an account to download the tools (this is free but they ask for motherboard/gpu model for community posts and verification that you can actually run their software)
Native testing of iOS apps is only possible on an Apple device. But there are some ways to overcome that.
Some reference to external iOS simulating platforms: https://fossbytes.com/best-ios-emulators-pc-windows-mac/
Can ios apps be compiled on the new M1 chipset?
Is there any schedule for official support?
The short answer is yes.
The latest version of XCode (version 12) is compiled as a universal app. This means that it runs on both Intel-based and Mac Sillicon machines natively. From Apple's website:
Xcode 12 is built as a Universal app that runs 100% natively on Intel-based CPUs and Apple Silicon for great performance and a snappy interface.* It also includes a unified macOS SDK that includes all the frameworks, compilers, debuggers, and other tools you need to build apps that run natively on Apple Silicon and the Intel x86_64 CPU.
This means that you should be able to compile iOS with the latest version of XCode without a problem. It would be kind of crazy for Apple to release professional hardware (MacBook Pro) without this capability.
Keep in mind that a number of third party applications may not work well on the ARM machines yet. VSCode is not currently supported on M1 devices (although Microsoft have said that it's coming). VSCode is an Electron based app which currently can't be emulated with Apple's Rosetta II platform. You might not use VSCode, but keep in mind that any Electron based apps that you use may not work straight away.
If you exclusively use XCode and don't critically rely on any third-party apps you should be ok.
EDIT: I just noticed that you tagged your post for react-native. Information is pretty slim for compatibility at the moment, so I would be cautious. If you need a Macbook Pro to do commercial work or school projects right now then you run the risk of things not working as intended. The M1 MacBooks will undoubtedly support everything that you need as a developer in the future and they're particularly great candidates for iOS development because of the parallels made possible by the shared ARM architecture.
If you're relying on a new machine to get work done right now, going with an Intel-based machine is probably the best option. For reference, I recently got an Intel-based 16" MacBook Pro with work because I need to get things done right now without any issues. The commercial value far outweighs the potential benefits that an M1 machine might bring in a year or two. If you're ok with running into some issues over the next few months, I'm sure that the M1 machines will provide plenty of value for years ahead.
While there are problems that do not allow compiling the application.
brew and cocoapods are installed in the console with rosetta enabled.
pod install / update fails because flipper and some parts of RN are not supported by the platform
if you use expo - without cli then everything is ok
updates: now cli working (after update all - homebrew, cocoapods and other to last version)
from what I know, iOS app only compiles on Mac os, so it should work with whatever macOS uses.
I have created a cocoa application which used the base SDK OS X 10.10. Some APIs which only exists in 10.10 are called. So it doesn't run correctly in the system which version is lower than 10.10.
So, i wan't to know is there any way can make my application run correctly in OS X 10.9 except rewrite it use lower SDK.? If not, What is the value of these new API. because i can't use it. If i used it application can't work in lower system.
Thanks!
You should use 10.10 as your Base SDK, and set your deployment platform to 10.9. You can then use respondsToSelector: and NSClassFromString to know if the class/method you're trying to use is available on the current OS, and degrade gracefully (for example, only make a feature available if you're running on the latest OS).
No, you'd have to rewrite it to use API calls which are available in 10.9.
The point of adding new calls to the API is because eventually everyone will have a device running the newer software - especially with Apple products - and then you'll be able to use it. Also, some people don't mind not being able to run on an older device. If they never added anything to the API then we would still be using the same things from 20 years ago.
If you think this is bad then try writing software for Android. The majority of devices are still running old API versions.
Essentially the answer is NO. You can't make an app which is built using the latest API's for 10.10 run in 10.9.
What the value of using the latest API's is depends on what you want to achieve. If you want to take advantage of the latest Apple technologies like iCloud Drive and CloudKit then you need 10.10. However, if your project doesn't need the these technologies then it may be worth making your app using a lower SDK.
It's worth noting that OS X 10.10 is free so you probably won't be alienating anyone by using the latest SDK. It's a different story for iOS where usually only the latest few iPhone and iPad models can be upgraded (e.g. iOS 8 from iPhone 4S and upwards).
Hope this helps.
OK, so here's my situation :
I've got Xcode 5.1.1 on a 10.9 (Mavericks) machine
I want to build my app so that it runs on 10.6 and later
SDKs installed : 10.6, 10.8, 10.9
What do I have to do to make sure it'll show up as "10.6 and later" compatible in the app store?
I managed to get it to compile fine with Base SDK set to either 10.8 or 10.9, and Deployment Target set to 10.6. Will that suffice?
P.S. I've tried compiling with Base SDK set to 10.6, as well, but there are so many errors to be fixed, that it'd be better if I could avoid it.
So any ideas?
Yes; using 10.9 SDK with the deployment target of 10.6 will work fine.
You may find you have conditional code-paths which must be determined at runtime, perhaps based on respondsToSelector, which will require some #pragmas in order to compile successfully.
The Deployment Target defines the minimum OS version that your app requires at run time.
The Base SDK defines the level of API features that are available at compile time.
Therefore you can use 10.9 as Base SDK when building apps that can run on 10.6 and upwards.
You just have to make sure to avoid code paths that use 10.7/10.8/10.9 APIs when your app runs on a 10.6 machine.
As trojanfoe already pointed out, you can use respondsToSelector: to check if a certain class/method is available.
Another way is to use NSAppKitVersionNumber:
if (floor(NSAppKitVersionNumber) <= NSAppKitVersionNumber10_8)
The NSAppKitVersionNumber constants for the latest SDK can be found in the AppKit Release Notes.
Further details can be found in Apple's SDK Compatibility Guide.
When I create a new OS X application project, I noticed many target options those confuse me quite a lot:
(1) The top-left setting of Xcode window:
(2) The "Base SDK":
(3) "Deployment Target":
(4) Architectures:
Here comes my questions:
For (2) and (3), I think it was clearer to understand. These are what I comprehend:
(2) This identifies what I develop with.
(3) This identifies what OS version my application will be used on.
Please tell me whether I am right...
But I could not understand (1). I just know that if I select 32-bit here, I could not use ARC.
Neither with (4), what are they? Are they represent the bit-width of the CPU? What was the difference between (1) and (4)?
I'll explain your items out of order.
The Base SDK
This defines the largest set of APIs you can use. You can use anything that existed as of the version number identified here. For example, if you use the 10.8 SDK, you can use -[NSColor CGColor] (introduced in 10.8), but not -[NSData base64EncodedDataWithOptions:] (first public in 10.9).
(Of course, you can also use anything older than that version.)
Accordingly, the SDK version is also known as the “max[imum] allowed” version in the Availability macros.
The SDK version also sometimes becomes important when Apple changes the behavior of an API. When they do that, they sometimes keep the old behavior around for applications linked with older SDKs. This is called an “on-or-after check”, as in “checks whether you're on 10.8 [SDK] or later”. (The concept and term pre-date Xcode having SDKs for each OS version. It used to just go by whatever OS you were running Xcode and building on.)
The Deployment Target
This is the minimum OS version you require. If something was removed in a prior version (rare, but it happens), you can't use it.
This tends to affect link-time and run-time things more than compile-time things. For example, ARC won't work if your deployment target is 10.5 or earlier.
Accordingly, the Deployment Target is also known as the “min[imum] required” version in the Availability macros.
The Info.plist can also specify a minimum OS version. Nowadays, this is set by default and it's set by macro expansion to the Deployment Target.
The Architectures build setting
Different CPUs have different architectures. Essentially, they fit into broad categories, such as:
PowerPC 32-bit (ppc)
PowerPC 64-bit (ppc64)
Intel 32-bit (i386)
Intel 64-bit (x86_64)
ARM 32-bit
ARM 64-bit
(PowerPC architectures aren't supported anymore. You can add them to the Architectures list, as ppc and ppc64, but Xcode will just ignore them.)
Macs nowadays have Intel processors. Almost all Intel Macs have 64-bit processors. You only need to worry about 32-bit Intel if you want to support Macs all the way back to 2006. That's probably more hassle than it's worth.
iOS devices run ARM processors, and most are still 32-bit. The A7 (iPhone 5S, iPad Air, iPad Mini with Retina Display) is 64-bit. But, if you run on an iOS Simulator, it's running on your Mac (it's a Simulator, not an emulator), so it'll target an Intel architecture (formerly always i386, but probably can now be x86_64 if needed).
The “top-left setting of Xcode window”
This is the build scheme and run destination. (Yes, it's two separate things in one pop-up menu. Actually, it's two separate pop-up menus in one control. Try it.)
“My Mac 64-bit” is the run destination. You'll be running the 64-bit version of your app on your Mac, not in an iOS Simulator or on an iOS device. Your choice for a Mac app is merely which architecture you want to run, and they should behave the same (this is, obviously, something you sometimes need to test).
iOS apps have more choices here. Some apps are iPhone-only, some are iPad-only, some are universal, and some may be set to build for both 32-bit and 64-bit architectures. You'll have a Simulator offered for each combination of form factor and architecture (e.g., iPhone Simulator 64-bit) you can run on. You'll also have the option to run your app on any iOS device that's connected and enabled for development (you get this prompt when you plug in the device in Xcode's sight).
TL;DR
Deployment Target is the lowest OS version your app will run on.
Base SDK is the highest OS version you can use stuff from. If it didn't exist yet, it doesn't exist at all for you.
Architectures are the set of hardware your app will run on.
Run Destination is the hardware you're going to run it on from within Xcode.
Just like with most OSes these days you can develop either a 32bit or a 64bit application. The "bitness" refers mostly to how memory addresses are structured (either using 32bit allowing so at most 4GB to address or 64bit (computation left as an exercise to the reader)). However the choosen architecture usually has more implications (like the missing ARC support for 32bit apps) but also how wide CPU registers are, how much memory a structure uses in RAM etc.
OS X also supports socalled fat binaryies that is, a bundle containing both 32bit and 64bit variants of your application. This is however only needed if you normally prefer to run 64bit code, but want your app also to run on OS versions that only support 32bit.
In XCode you can define for what architecture to build your project, either 32bit only, 64bit only or a fat bundle. In the project settings you can set what is allowed and in the top bar in XCode you can quickly switch between the allowed architectures (your questions 1 and 4).
The base SDK determines what you want to use to compile your application. If you select for instance 10.7 you cannot use new APIs that were introduced in 10.8 or 10.9 (which might perfectly be ok if you want your application to run on earlier OS versions only). However if you want to dynamically use new features if they are availble you'd select the latest OS as base SDK and check in code what OS you are running on and only use new features if they are available. It is totally ok to compile an application with access to new features and run it on older systems if you don't use the new APIs there (they are late-bound and hence only crash when you access them the first time and they are not available).
The deployment target determines the minimum OS version your application needs to run properly. This is a runtime check done when the application is started. The OS will refuse to start an application that is made for a later version.