Mac OS X Application Development

From Appmethod Topics
Jump to: navigation, search

Go Up to Types of Multi-Device Applications You Can Create

You can use Appmethod to create Mac OS X applications, and you can use your Mac as the required intermediate platform for iOS apps.

From the hardware point of view, in addition to the development PC, you need a Mac connected with the development computer (where Appmethod is installed); for example, using a local area network (LAN). See FireMonkey Platform Prerequisites for a list of system requirements, both for your development PC and for the Mac. See also Working with a Mac and a PC.

The Object Pascal compiler for Mac OS X is DCCOSX.

The C++ compiler for Mac OS X is BCCOSX. The C++ linker for Mac OS X is XLINK.

Setting Up Your Development Environment for Mac OS X

  • Physical Connection: Ensure that Appmethod can connect with the target Mac:
    However, if the OS X app does not have an assigned connection profile, and you attempt to perform an operation that requires a connection profile, the IDE displays the following message:
    A connection profile is required for this operation but has not been assigned.
    Would you like to assign or create a profile now?
    Then the IDE guides you through the necessary steps in creating a connection profile. On the Platform Properties dialog, you can assign an existing profile to the target platform, or select Add New to create a new connection profile to assign to the target platform instead.
  • Platform Assistant: On the Mac, install the Platform Assistant and run it.
  • Target Platform: In the IDE, set the target platform. When you create a Object Pascal or Appmethod C++ multi-device application, Appmethod sets Win32 as the default target platform.
    To change the target platform to OS X:
    1. Right-click the Target Platforms node in the Project Manager.
    2. Click Add Platform and select OS X.
  • Connection Profile: In the IDE, create and assign a connection profile (a group of settings that characterize the connection to your target machine; see Creating and Testing a Connection Profile on the Development PC).
  • For C++ Development:
    • Xcode and Xcode Command Line Tools:
      For C++ OS X applications, you need to install Xcode on the Mac. You need to install the Xcode Command Line Tools as well in order to deploy applications to the Mac App Store.
    • SDK:
      For C++, add an SDK, which consists of a set of files (headers and libraries) that are pulled from the machine running the Platform Assistant server into your development system, for compiling and linking. See Adding a Mac OS X or iOS SDK.

Developing Your Application

Using Frameworks in Mac Apps

This section describes some aspects of multi-device application development that are specific to the Mac OS X target platform. For general multi-device development documentation, see Developing Multi-Device Applications.


Some RTL units that provide basic functionality are common for Mac and Windows, such as System.pas or System.SysUtils.pas.

A number of RTL units are Mac-only (see Mac Objective-C Frameworks). These units are prefixed with the Macapi or Posix unit scope.

See also OS X C RTL.


The FireMonkey framework is ideal for the Mac OS X target platform, and it also supports both Win32 and Win64. See FireMonkey Platform Prerequisites.

Mac C RTL (for C/C++ Development)

BCCOSX uses header files from several locations for compilation.

The C RTL is distributed in two locations:

Include Path Type





This directory contains C/C++ RTL header files (.h) provided by Appmethod. Some of these files include C/C++ header files from $(SYSROOT)\usr\include. For more information see OS X C RTL.



This directory contains C/C++ RTL Mac OS X header files cached on Windows. It is the SDK root directory.

For compilation, Appmethod requires header files that reside on the Mac in the /usr/include directory. If you do not have such a directory on your Mac, then you must install Xcode. With the help of PAServer.exe, the Platform Assistant server, Appmethod automatically copies the header files from Mac to Windows (from /usr/include to $(SYSROOT)\usr\include) when you add an SDK from the SDK Manager page.

Most of the Mac OS X C RTL is standard, and nonstandard characters are not supported.

Mac C Frameworks (for C/C++ Development)

Mac OS X frameworks provide various useful functions for writing platform-specific software. Some frameworks are C-based and can be included in a Appmethod Appmethod C++ project. Some frameworks are Objective-C-based (such as Foundation) and can be used only through Object Pascal interfaces (see the following section).

In order to include a Mac C framework in a Appmethod project, you must edit the SDK that you use. Open the SDK Manager page and click the New.bmp (Add a new path item) button from the right hand side. In the Add Remote Path Item or Edit Remote Path Item dialog, specify the following:

  • Framework remote path (example: /System/Library/Frameworks)
  • Framework name (example: CoreFoundation)

Back to the SDK Manager page, press Update Local File Cache to update the SDK local files.

For more information about using frameworks with BCCOSX, see --framework and OpenGL Multicolor Tetrahedron (C++).

Mac Objective-C Frameworks (Macapi)

The RTL contains a number of units that provide Object Pascal interfaces to Mac frameworks written in Objective-C. These units are scoped with Macapi (from Mac API) and typically located in the /source directory of your product installation:

  • Macapi.AppKit
  • Macapi.CocoaTypes
  • Macapi.Consts
  • Macapi.CoreFoundation
  • Macapi.CoreGraphics
  • Macapi.CoreServices
  • Macapi.CoreText
  • Macapi.Foundation
  • Macapi.ImageIO
  • Macapi.Mach
  • Macapi.ObjCRuntime
  • Macapi.ObjectiveC
  • Macapi.OCMarshal
  • Macapi.OpenGL
  • Macapi.QuartzCore
  • Macapi.Security
  • Macapi.SystemConfiguration

The FireMonkey framework relies on some of these units.

For help on these API, see the Apple documentation at Mac Developer Library.

Resolving Ambiguities: 'Byte' and 'System::Byte' on OS X

Both Object Pascal and the OSX SDK headers define the Byte type. Thus, you might run into ambiguity errors when using plain Byte.

For example, the following code:

#include <System.hpp>
DynamicArray<Byte> AByteArray;

results in error E2015 Ambiguity between 'function1' and 'function2' (C++) when compiled for OS X:

Error E2015 t.cpp 2: Ambiguity between 'Byte' and 'System::Byte'
*** 1 errors in Compile ***

To resolve the issue, you should explicitly specify the definition of Byte that you want to use, that is, either of the following:

Object Pascal OS X SDK

For example, the following code should compile with no errors:

#include <System.hpp>
DynamicArray<System::Byte> AByteArray;

Exception Handling

System.SysUtils contains a number of exception classes that represent non-language/hardware exceptions. These exception classes derive from EExternal. The following exception categories are covered:

  • Floating-point exceptions
  • Integer divide exceptions
  • Privileged instruction violations
  • Memory access violations

On the Mac, most of the EExternal exceptions originate as Mach exceptions. The only ones that do not originate as Mach exceptions are CTRL+C (EControlC) and CTRL+BREAK (EQuit).

If you use assembly routines, then see PC-Mapped Exceptions, Unwinding Assembly Routines.

Processing of Mach Exceptions

For Mach exceptions, the RTL from System.SysUtils creates a thread that listens for exception notifications from the operating system. You just have to include in your code the System.SysUtils unit. When the listening thread receives a Mach exception notification, it transforms the Mach exception into the corresponding Pascal language exception derived from EExternal, as appropriate, and raises/throws the Pascal exception to the user thread that caused the original Mach exception.

If you want to directly work with Mach exceptions, then be aware that, by including System.SysUtils, a dedicated thread is started for listening Mach exceptions. You can investigate the System.Internal.MachExceptions.pas source to make sure you do not interfere with the RTL.


For CTRL+C and CTRL+BREAK, the application installs signal handlers. (OS X does not create Mach exceptions for CTRL+C and CTRL+BREAK.)

The SIGINT and SIGQUIT handlers are in conformity with the standards that define the way shell applications must treat CTRL+C and CTRL+BREAK.

We strongly recommend that you do not override the SIGINT and SIGQUIT handlers. However, if you do this, you do not receive EControlC and EQuit exceptions.

Documentation for Mac Libraries

You can obtain the Mac OS X documentation at the Mac OS X Developer Library. Appmethod does not provide help for the libraries you might need to use on the Mac.

You can also register as a Mac developer (free of charge) at the Mac Dev Center. Being a registered member of the Apple Developer Program enables you to distribute apps in the App Store (this is along with other requirements, such as a developer certificate and a provisioning profile). For more information, see

Deploying Your Final Mac OS X Application

Before each release of your Mac OS X application, you should check that every setting is properly configured. See Preparing a Mac OS X Application for Deployment.

To self-distribute your Mac OS X application you can simply build your application and distribute the resulting binaries to your clients. See Distributing Applications Outside the Mac App Store in the Apple documentation for more information.

If you want to publish your application on the Mac App Store, however, you must follow some additional steps. See Submit your application to the Mac App Store for detailed steps.

Mac OS X Topics

See Also

Code Examples