If you… | Then 4 KB means… | Localization impact |
Translate on the server (full strings in every payload) | You’re burning bytes fast—each extra locale is pure size. | Fine for short marketing blurbs; risky for chat or long-form copy. |
Use loc-key look-ups on device | Payload stays tiny (just a key + args). | Requires an app update for any new phrase; ignores in-app language toggles. |
Lean on a Notification Service Extension | You can ship one slim “ID + args” and fetch text on-device. | Best flexibility, but the final assembled message must still obey 4 KB. |
Strategy | Good for… | Watch for… |
Server‑side strings | marketing copy and campaigns where you can treat the push like an email. You know every language up front and can change text without shipping a new app. | Every extra locale adds bytes. Multiple locales in one payload can quickly breach the 4 KB limit. |
loc‑key + args | simple apps where the system language matches the app language. You include a key and optional arguments (e.g., username), and iOS looks up the string in your bundled Localizable.strings file. | You must ship translations with the app; changing copy means shipping an update. Cannot honour an in‑app language switch because the OS always uses the device language. |
Service extension | advanced apps: you can build messages dynamically, honour in‑app language settings, and even fetch rich media. The extension runs before display and can replace the title, subtitle, and body. | Requires an additional target and App Group; your code must call the completion handler within ~30 seconds or the original message appears. |
Platform type | Pros | Cons |
Built‑in localization (e.g., OneSignal, Airship, Pushwoosh) | Their APIs accept multiple language variants in a single call. The platform detects the user’s language via its SDK and picks the right translation. You don’t need to bundle Localizable.strings in your app. Marketing teams can add or update translations via web dashboards without an app release. OneSignal’s example shows sending contents and headings fields with en, es, and fr keys; unspecified languages fallback to English. | Vendor lock‑in: you depend on the platform’s features and pricing. Switching later requires migrating your translation data and potentially rewriting your push logic. Payload size is still limited by APNs, so don’t embed dozens of languages in the same message. |
Standard APNs (e.g., Firebase Cloud Messaging, Amazon SNS, Pusher Beams) | These services act as pass‑through. You implement localization using loc‑keys and possibly a service extension. You retain full control and can migrate providers easily. | More developer work: you must manage language preferences, build translation infrastructure, and ensure plural rules. Some vendors offer templating (e.g., Braze’s Liquid) but you still manage translations yourself. |
Hybrid tools (e.g., Braze, CleverTap) | Provide enhanced targeting (locale tags) and templating (Braze’s Liquid) but ultimately rely on Apple’s localization mechanisms. Useful if you already use the platform for analytics or campaigns. | Still require client-side localization code and don’t fully solve the in-app language problem (you must ship .strings or a service extension anyway). |