Who owns camera permissions?<\/strong>\u00a0Your app, on every target; the SDK renders once frames arrive.<\/li>\n<\/ul>\n\n\n\nThe staffing symmetry deserves one more note: because the prop model is identical across targets, a designer moving between the iOS and Flutter projects changes codebases without changing content practices. The catalogue, the authoring platform, and the publish pipeline are the same surface \u2014 muscle memory transfers, and so does institutional knowledge.<\/p>\n\n\n\n
That consistency is invisible when it works and expensive when absent: teams that forked prop content per platform spend their seasons reconciling catalogues instead of shipping them. The one-library arrangement exists precisely so that seasons stay for shipping.<\/p>\n\n\n\n
However the target list grows \u2014 a desktop client, a smart-hardware variant \u2014 the prop library arrives with it, complete, on day one.<\/p>\n\n\n\n
One library, four targets, zero content forks \u2014 the prop roadmap stays that simple as it grows.<\/p>\n\n\n\n
One more planning observation: prop campaigns stop being platform campaigns. A launch that would once have needed an iOS week, an Android week, and a framework follow-up is one publish and one verification pass \u2014 the team’s calendar frees for the creative work that differentiates the product in the first place.<\/p>\n\n\n\n
Fewer platform weeks, more creative weeks \u2014 the arithmetic of one library.<\/p>\n\n\n\n
The same reasoning applies to QA ownership: because verification is per family rather than per platform permutation, one reviewer covers the season. Review effort scales with content, not with the target list.<\/p>\n\n\n\n
Put together, the four-target arrangement reads like a single-target one: one library, one calendar, one verification pass \u2014 multiplied across every build the product ships. That is the whole point, and the whole saving.<\/p>\n\n\n\n
One library, four targets, zero forks \u2014 and every season arrives everywhere the same day.<\/p>\n\n\n\n
And when a fifth target appears \u2014 a desktop client, a smart-hardware variant \u2014 it joins the same library the same week: integration work, never content work.<\/p>\n\n\n\n
However the build list grows \u2014 a fifth target, a hybrid module, a new client \u2014 the sticker library arrives complete on each new surface, and the roadmap keeps its single content truth.<\/p>\n\n\n\n
Four targets today, whatever tomorrow \u2014 the library was built for the growth, and the growth was built into the library.<\/p>\n\n\n\n
The four-target story, in closing, is not about the targets \u2014 it is about the team that never has to choose between them. Ship where the users are; the library follows the product wherever it goes next.<\/p>\n\n\n\n
FAQ<\/h2>\n\n\n\n
Can we start native and add Flutter later?<\/strong>
Yes \u2014 the same prop packages resolve on the new target from day one; the content investment carries over untouched.<\/p>\n\n\n\nDo gesture triggers work through React Native?<\/strong>
Yes \u2014 gesture events arrive at the JavaScript layer as coarse events; detection itself runs natively on the frame stream.<\/p>\n\n\n\nHow does QA verify props across four targets?<\/strong>
Verify each family once per target family; because engine and packages are shared, differences surface as platform behaviour rather than prop differences.<\/p>\n\n\n\nCan props run alongside beautification on the cross-framework path?<\/strong>
Yes \u2014 the hosted pipeline runs the same stack, so a Flutter user can wear smoothing, a filter, and a 3D prop together.<\/p>\n","protected":false},"excerpt":{"rendered":"AR face props on iOS, Android, Flutter, and React Native come from one library: the same 2D and 3D sticker sets, anchored to detected facial features, tracked per frame, and resolved from the same packages on every target. Native teams link the engine directly; Flutter and React Native teams reach the identical prop stack through […]<\/p>\n","protected":false},"author":1,"featured_media":587,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[378,411,40,368,377,369,12],"class_list":["post-586","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-face-ar-sdk","tag-android","tag-ar-face-props","tag-face-ar-sdk","tag-flutter","tag-ios","tag-react-native","tag-video-editing"],"_links":{"self":[{"href":"https:\/\/en.meishesdk.com\/blog\/wp-json\/wp\/v2\/posts\/586","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/en.meishesdk.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/en.meishesdk.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/en.meishesdk.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/en.meishesdk.com\/blog\/wp-json\/wp\/v2\/comments?post=586"}],"version-history":[{"count":1,"href":"https:\/\/en.meishesdk.com\/blog\/wp-json\/wp\/v2\/posts\/586\/revisions"}],"predecessor-version":[{"id":588,"href":"https:\/\/en.meishesdk.com\/blog\/wp-json\/wp\/v2\/posts\/586\/revisions\/588"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/en.meishesdk.com\/blog\/wp-json\/wp\/v2\/media\/587"}],"wp:attachment":[{"href":"https:\/\/en.meishesdk.com\/blog\/wp-json\/wp\/v2\/media?parent=586"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/en.meishesdk.com\/blog\/wp-json\/wp\/v2\/categories?post=586"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/en.meishesdk.com\/blog\/wp-json\/wp\/v2\/tags?post=586"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
![\"AR](\"https:\/\/en.meishesdk.com\/blog\/wp-content\/uploads\/2026\/10\/2026102307465469.png\")
<\/a><\/figure>\n\n\n\n