This article provides guidance on C/C++ bindings for mobile applications, covering JNI Android NDK, Objective-C++ bridging iOS, and integration of libraries like OpenCV and FFmpeg. We specialize in C/C++ bindings for mobile applications, ensuring smooth app store review with properly integrated native libraries. When integrating a native C++ library into a mobile app, the key task is writing correct and performant bindings. A typical mistake is forgetting to free memory after a JNI call, leading to leaks and crashes. We'll cover how to avoid this on Android and iOS, using OpenCV and FFmpeg as examples.
C and C++ libraries are the standard in performance-critical areas: video processing (FFmpeg, x264), cryptography (OpenSSL, libsodium), computer vision (OpenCV), audio (Opus, WebRTC), physics engines (Bullet, Box2D). Mobile platforms provide direct access to native code—the question is how to write the binding correctly. Our experience with over 50 projects shows that a well-designed binding saves up to 30% of integration and testing time. Clients typically save $10,000–$30,000 by outsourcing to us compared to building in-house.
Passing data through JNI without copying
On Android, native code is called via JNI (Java Native Interface). According to the Android NDK Developer Guide, JNI provides a way for Java code to call native functions and vice versa. The binding is a layer of C/C++ functions with names like Java_com_example_MyClass_nativeMethod, which Dalvik/ART automatically links to Java/Kotlin methods marked external.
// Kotlin class ImageProcessor { external fun processFrame(pixels: ByteArray, width: Int, height: Int): ByteArray companion object { init { System.loadLibrary("imageprocessor") } } } // C++ extern "C" JNIEXPORT jbyteArray JNICALL Java_com_example_ImageProcessor_processFrame( JNIEnv* env, jobject thiz, jbyteArray pixels, jint width, jint height) { auto* input = env->GetByteArrayElements(pixels, nullptr); // invoke OpenCV or custom logic env->ReleaseByteArrayElements(pixels, input, JNI_ABORT); // ... } A critical point is memory management at the JNI boundary. GetByteArrayElements with flag 0 copies the array (safe but slow). GetByteArrayElements with JNI_ABORT does not copy changes back. For performant image processing, use GetDirectBufferAddress with ByteBuffer.allocateDirect()—shared memory without copying. Using DirectByteBuffer is 2–3 times faster than copying via GetByteArrayElements for streaming data. JNI in-place processing reduces latency by up to 40% compared to copying. Understanding JNI memory management is crucial for app store review of native libraries.
Exception Handling in JNI
C++ exceptions do not automatically pass through JNI. Wrap in try/catch on the C++ side, throw a Java exception via `env->ThrowNew(env->FindClass("java/lang/RuntimeException"), message)`. Always manage global references carefully to avoid leaks.CMakeLists.txt via Android NDK: specify target_link_libraries to link a precompiled .a or .so library. For OpenCV, find_package(OpenCV REQUIRED) if building from sources, or manually link libopencv_core.a + libopencv_imgproc.a via add_library(opencv STATIC IMPORTED). Binary size matters: OpenCV static linking adds 8–15 MB per ABI. Use abiFilters "arm64-v8a", "x86_64" to remove unnecessary ABIs. CMake cross-compilation for Android iOS is streamlined with separate toolchain files.
Handling C++ Libraries without iOS Support
On iOS, C code is called directly—Swift and Objective-C run in the same runtime as C. For C++ you need Objective-C++ (.mm files).
// ImageProcessorBridge.mm — Obj-C++ wrapper #include "opencv2/opencv.hpp" #import "ImageProcessorBridge.h" @implementation ImageProcessorBridge - (NSData *)processFrame:(NSData *)pixelData width:(int)w height:(int)h { cv::Mat mat(h, w, CV_8UC4, (void*)pixelData.bytes); // processing NSData *result = ...; return result; } @end Swift calls Objective-C via a bridging header (-Bridging-Header.h). You cannot call C++ directly from Swift until Swift 5.9, which introduced experimental Swift/C++ Interop—allows importing C++ types directly via import CxxModule. In production with Xcode 15, this is already a viable option for simple C++ APIs without templates and virtual inheritance. This C++ library iOS Swift interop approach simplifies bridging.
XCFramework with native library. When linking a precompiled C++ library, build an .xcframework using lipo create for Device (arm64) and Simulator (arm64 + x86_64). Apple Silicon Simulator requires arm64, Intel Mac requires x86_64; a fat binary via lipo combines both. Native library build arm64 ensures compatibility across devices.
OpenCV on iOS. The official opencv2.framework (or xcframework) is integrated via Cocoapods (pod 'OpenCV') or manually. Size: ~160 MB in debug, with bitcode the linker selects only needed modules. For App Store, strip in Release build is important.
Case study: real-time video processing
An app for processing video stream from camera (filters, face recognition): iOS — AVFoundation provides CMSampleBuffer → convert to cv::Mat via CVPixelBufferGetBaseAddress → OpenCV filter → display via MTLTexture (Metal). Android — Camera2 API → ImageReader with format YUV_420_888 → convert via libyuv to RGBA → OpenCV → SurfaceView. Bindings are written in Objective-C++ (iOS) and JNI (Android). Performance: frame processing 1920×1080 — 8–12 ms on iPhone 13, 15–22 ms on mid-range Android. Over 10 million frames processed in production.
Build and integration
CMake—cross-platform build system for both Android NDK and iOS (via CMake toolchain for iOS). One CMakeLists.txt for native logic, different toolchain files.
For complex C++ libraries with autoconf/Makefile—configure && make is run via cross-compilation toolchain NDK or iOS. This is more labor-intensive but standard practice for OpenSSL, libsodium, FFmpeg.
What's included in the work
- Analysis of the target library API: identifying exported functions, data types, dependencies.
- Binding design: choosing the approach (JNI, Obj-C++, Swift/C++ Interop), interface agreement.
- Implementation: writing code in Swift/Obj-C/Kotlin and C/C++, CMakeLists, Xcode project integration.
- Testing: unit tests, integration tests, performance tests.
- Documentation: binding description, usage examples, build instructions.
- Support: assistance with App Store Review, updates for new OS versions.
We handle this volume of work turnkey. With over 7 years of experience and 50+ successful projects, we'll evaluate your project in 1–2 business days. Our binding development services start at $5,000 for simple libraries, with typical projects ranging from $8,000 to $25,000. Contact us for a consultation.
How to proceed
- Send us your library source and API documentation.
- We analyze and provide a timeline and cost estimate.
- We develop bindings with test coverage.
- We deliver and support integration.
Timelines (approximate)
| Binding type | Estimated timeline |
|---|---|
| Simple C library (crypto, compression) | 2–4 weeks |
| C++ library with non-trivial API (OpenCV, FFmpeg) | 4–8 weeks |
| Full integration with UI pipeline | 2–4 months |
The cost is calculated individually—depends on the complexity of the target library API and the availability of existing documentation. Order binding development—get a ready-made solution with a compatibility guarantee.