Many teams face two main problems when implementing face swap: app rejection due to store policy violations and insufficient swap quality—artifacts, skin color mismatch, unnatural contours. Let's examine the architecture of a production-ready face swap pipeline, including on-device and API approaches, post-processing, content moderation, and App Store and Google Play syndicate requirements. Contact us to evaluate your project.
Why on-device face swap is rare?
Models like SimSwap (300 MB), FaceShifter (250 MB), GHOST (100 MB) require GPU. TFLite ports lose ~15% quality. MediaPipe Face Mesh provides 468 landmarks in real time — we use them for alignment. However, the swap itself requires neural network inference. On-device implementation is possible via Core ML on iPhone 14 Pro+: a distilled model processes a frame in 1–3 seconds. On Android — TFLite GPU delegate, but behavior varies (Adreno 730 vs PowerVR). Production apps often use APIs: InsightFace, Akool, DeepFaceLab. Akool face_swap endpoint returns results in 5–15 seconds.
The API approach is faster to implement and saves device resources, but on-device guarantees privacy and offline work. We offer both options depending on client tasks.
| Library | Platform | Key Features |
|---|---|---|
| MediaPipe Face Mesh | Android/iOS | 468 landmarks, real-time, <30ms |
| ML Kit Face Detection | Android/iOS | 5+ faces, classifications, no mesh |
| Parameter | On-device | API |
|---|---|---|
| Processing time | 1–3 s (Core ML) | 5–15 s |
| Quality | Depends on model (~10% loss) | High (full model) |
| Privacy | Data on device | Server transmission |
| Hardware requirements | GPU (A13+, Adreno 6xx) | Any device with internet |
| Infrastructure cost | None | Per-request pricing |
How is post-processing performed after face swap?
Even a good face swap produces artifacts. On iOS we apply CIFilter(name: "CIGaussianBlur") on the face mask and CIBlendWithMask for smooth transitions; for complex cases — Metal Performance Shaders. Skin color between face and neck may mismatch — colour transfer via LAB color space with CIColorCube filter. On Android we use OpenCV for GaussianBlur and inpaint. Infrastructure savings with on-device can be significant compared to API under high load.
Client-side processing pipeline
Preprocessing is needed before server submission:
// Android: face detection and cropping before submission class FacePreprocessor(private val context: Context) { private val detector = FaceDetection.getClient( FaceDetectorOptions.Builder() .setPerformanceMode(FaceDetectorOptions.PERFORMANCE_MODE_ACCURATE) .setLandmarkMode(FaceDetectorOptions.LANDMARK_MODE_ALL) .build() ) suspend fun extractFace(bitmap: Bitmap): FaceExtractionResult { val image = InputImage.fromBitmap(bitmap, 0) val faces = detector.process(image).await() if (faces.isEmpty()) throw FaceSwapError.NoFaceDetected if (faces.size > 1) throw FaceSwapError.MultipleFaces val face = faces.first() val bounds = face.boundingBox // Expand bounds by 40% for better context val expandedBounds = expandRect(bounds, 0.4f, bitmap.width, bitmap.height) val croppedBitmap = Bitmap.createBitmap( bitmap, expandedBounds.left, expandedBounds.top, expandedBounds.width(), expandedBounds.height() ) return FaceExtractionResult(croppedBitmap, face.headEulerAngleY) } } Head rotation angle (headEulerAngleY) is important: if deviation >30°, swap quality drops sharply — the user should be warned.
Work process
- Analytics: determine source (photo/video), choose approach (on-device/API), evaluate metrics.
- Design: architecture development, model selection (Core ML/TFLite), UI design.
- Implementation: integrate face detection (MediaPipe, ML Kit), preprocessing, request submission, post-processing.
- Testing: check on different devices, A/B quality testing, stress tests.
- Deployment: publish to App Store/Google Play, configure moderation, monitor.
What's included in the work
The full package includes:
- Architecture documentation and API integration specs (endpoint specifications, postman collection).
- API access (test keys, sandbox).
- Client team training (2-3 workshops on pipeline and moderation).
- Technical support during implementation and after release (1 month).
- Integration of watermark and disclaimer, Terms of Service setup per store requirements.
Legal restrictions and moderation
Face swap is subject to strict requirements under App Store Review Guidelines (Guideline 1.1 Objectionable Content). Apple rejects apps that:
- allow inserting another person's face without explicit consent;
- lack watermark or AI-generated labeling;
- could be used for deepfakes.
Mandatory minimum: watermark on result, explicit disclaimer in onboarding, Terms of Service prohibiting use of real faces without consent, content reporting system.
More on Store requirements
According to Apple's policy, apps with AI face swap must ensure transparency of AI use and ability to report violations. Google Play also requires AI content labeling.Content moderation on the server: before generation, run through Amazon Rekognition DetectModerationLabels or Google Cloud Vision Safe Search. If input photo is flagged — reject on backend, do not proceed to generation.
Storage and deletion
Face swap results should not be stored on the server longer than needed for client delivery. Standard practice: TTL 24-48 hours, then auto-delete from S3/GCS. Input photos — delete immediately after processing.
Timeline
Basic API integration with face detection and result display — 4-6 days. With blending post-processing, content moderation, watermarking, and store policy compliance — 3-4 weeks. Cost is calculated individually after auditing your project. We are a team of certified developers with 5+ years of experience in mobile development and AI, having completed 10+ face swap projects. Order a test integration or get a consultation — we'll evaluate your project for free.