Mobil push értesítések 2026 ban · iOS és Android playbook magyar appokra
iOS opt in 2026 ra 38 százalék alá esett. Android 13+ on a permission prompt is bekerült. Itt a teljes magyar push playbook.
iOS opt in 2026 ra 38 százalék alá esett. Android 13+ on a permission prompt is bekerült. Itt a teljes magyar push playbook.
A push értesítés a mobil app egyetlen csatornája arra, hogy a user nyissa meg újra. 2026 ban viszont mind az iOS, mind az Android oldalon szigorodtak a feltételek, és ami 2023 ban opt in mágia volt, az most 38 százalékos átlag. Ez a poszt arról szól, mit építünk minden új magyar mobil appba (és milyen hibákat látunk a meglévőknél a code review során).
Push nem marketing csatorna. Ha annak használod, az opt in 6 hónap alatt 12 százalékra esik. A szabály egyszerű: minden push olyan, hogy ha a user kapja, az kéri tőle, hogy nyissa meg az appot · ne csak tájékoztassa.
Két magyar fintech app, egy retail, egy news és egy logisztikai app push opt in számai 2026 első negyedévében: a fintech 31-34 százalék, a retail 22 százalék, a news 41 százalék, a logisztikai 73 százalék (mert ott funkcionális). Az iOS notification center ből az ún 'time sensitive' kategóriát is felhasználjuk, ott a delivery 1.6 szor hatékonyabb, de a felhasználás csak 14 napos próbára engedett.
A pre permission prompt (saját UI ami magyarázza, miért fontos a push) a 2024 es OS verzió óta nem nőtte ki magát. A natív iOS prompt minden esetben felülírja, és ha egyszer 'Don't Allow' a válasz, akkor az appon belül onboarding végén már nem látszik. Akkor mutasd meg, amikor első értelmes művelet után vagy: pl regisztráció kész és van valami tartalom a karbantartás alatt.
Az Android 13 ban (2022, de most már a magyar piaci penetráció 78 százalék fölött) bevezetett `POST_NOTIFICATIONS` runtime permission t kötelezően kell kérned, különben a system csendben dropolja a push okat. A 2026 ban kibocsátott appoknál látjuk, hogy a fejlesztők elfelejtik az `android:targetSdkVersion = 34` kombinációval rákényszeríteni magukat.
// Android 13+ kötelező runtime permission
class PushPermissionManager(private val activity: Activity) {
private val launcher = activity.registerForActivityResult(
ActivityResultContracts.RequestPermission()
) { granted ->
Analytics.track("push_permission", mapOf("granted" to granted))
if (granted) FCM.subscribeToTopics()
}
fun requestIfNeeded() {
if (Build.VERSION.SDK_INT < Build.VERSION_CODES.TIRAMISU) return
if (ContextCompat.checkSelfPermission(
activity, Manifest.permission.POST_NOTIFICATIONS
) == PackageManager.PERMISSION_GRANTED) return
// shouldShowRequestPermissionRationale igaz esetén
// saját magyar nyelvű magyarázó UI t mutatunk először
if (activity.shouldShowRequestPermissionRationale(
Manifest.permission.POST_NOTIFICATIONS
)) {
RationaleDialog.show(activity) { launcher.launch(
Manifest.permission.POST_NOTIFICATIONS
) }
return
}
launcher.launch(Manifest.permission.POST_NOTIFICATIONS)
}
}A device token nem örök. A user telepíti újra az appot, restoreol másik telefonra, frissíti az iOS t · új tokent kapsz. A tipikus hibás kódbázisban a token mentés egyszer megy, ezután soha. Ha ezt nem javítod, a 90 napos delivery rate egyenletesen lefelé húz. A megoldás: minden alkalommal frissítsd a tokent a backenden, amikor a `didRegisterForRemoteNotificationsWithDeviceToken` lefut · ne csak akkor, ha az első login.
func application(
_ application: UIApplication,
didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data
) {
let token = deviceToken.map { String(format: "%02.2hhx", $0) }.joined()
// Mindig elküldjük, akkor is, ha azt hisszük változatlan.
// A backend deduplikál (token + user_id + bundle_id index).
Task {
await PushBackend.register(
token: token,
env: PushEnv.current, // sandbox / production explicit
userId: Auth.currentUserId
)
}
}A `PushEnv.current` konkrét: a sandbox és a production APNs token formátum azonos, de a server endpoint nem. A leggyakoribb hiba az, hogy a TestFlight ben sandbox tokent regisztrálsz, és a backend prod APNs re küldi. A delivery 100 százalékban hibás, és nem kapsz error logot, csak '410 Gone' a feedback service ből.
A Google a legacy FCM HTTP API t 2024 június 20 án kapcsolta le. Ha 2026 ban még egy 2 éves Magento push moduljából push olsz, valószínűleg az `fcm.googleapis.com/fcm/send` endpointot hívod (ami már nem létezik). Át kell állnod a `fcm.googleapis.com/v1/projects/{project_id}/messages:send` címre, ami service account JSON nal és OAuth 2.0 access tokennel megy. A legacy API key alapú authentikáció már történelem.
import { GoogleAuth } from "google-auth-library";
const auth = new GoogleAuth({
credentials: JSON.parse(process.env.FCM_SERVICE_ACCOUNT!),
scopes: ["https://www.googleapis.com/auth/firebase.messaging"],
});
export async function sendFcm(token: string, title: string, body: string, data: Record<string, string>) {
const client = await auth.getClient();
const accessToken = (await client.getAccessToken()).token;
const projectId = process.env.FCM_PROJECT_ID!;
const res = await fetch(
`https://fcm.googleapis.com/v1/projects/${projectId}/messages:send`,
{
method: "POST",
headers: {
Authorization: `Bearer ${accessToken}`,
"Content-Type": "application/json",
},
body: JSON.stringify({
message: {
token,
notification: { title, body },
data, // mindig string értékekkel · az FCM csak ezt fogadja el
android: { priority: "high", ttl: "3600s" },
},
}),
}
);
if (!res.ok) {
const err = await res.json();
if (err.error?.details?.[0]?.errorCode === "UNREGISTERED") {
await PushBackend.markTokenInvalid(token);
}
throw new Error(`FCM ${res.status}: ${JSON.stringify(err)}`);
}
}Egy ország · egy időzóna app esetén ez egyszerűbb, mint a multi country, de van három magyar specifikum. Egy: a delkó (delivery confirmation) sokszor nem érkezik vissza Telekom 4G hálózatról este 22 óra után, mert a TCP keep alive nem hagyja életben. Push ütemezésnél ezt vedd figyelembe. Kettő: a magyar morfológia miatt a 'Szia János!' és 'Szia Eszter!' közötti karakterszám eltérés a body lock screen ön levághatja a CTA t. Tartsd 65 karakter alatt. Három: a 'határozott / határozatlan' nyelvtani különbséget a localization fájlban kell megoldani, mert egy automata fordítás megöli ('a vásárlás' vs 'vásárlás').
A push tap után a user ne a homepage en landoljon. A deep link iOS oldalon Universal Link (apple-app-site-association fájllal a domainen), Android oldalon App Link (assetlinks.json fájllal). 2026 ban már kötelező mindkettő, mert a custom URL scheme (mintapp://) iOS 17 től tiltott egyes esetekben. A deep link payloadot a push data ban szállítsd, ne a notification body ban.
{
"message": {
"token": "...",
"notification": { "title": "Új rendelés", "body": "#A4291 elindult" },
"data": {
"deep_link": "https://app.peldatar.hu/orders/A4291",
"intent": "order_status",
"order_id": "A4291",
"campaign_id": "april_orders_2026"
},
"apns": {
"payload": {
"aps": {
"alert": { "title": "Új rendelés", "body": "#A4291 elindult" },
"category": "ORDER_UPDATE",
"thread-id": "orders"
}
}
}
}
}Az APNs ingyenes, az FCM is. A költség a backend oldalon van: ha napi 100 ezer push ot küldesz, és minden push előtt egy database lookup van (token + user prefs + segment), akkor a Postgres terhelés komoly. Az általunk épített rendszerekben a push ot egy Redis sorba tesszük, és a worker batchben olvassa, max 500 db onként. A 100k push így 200 worker iteráció, amit egy gép 4 perc alatt megcsinál.
Mindig logold a push ID t a backenden és az appon is (a FCM v1 visszaad egy `name` mezőt, az APNs a `apns-id` headert). Ez a egyetlen módja annak, hogy egy 'nem kaptam meg' jellegű ügyfél jegyet vissza tudd vezetni a delivery vagy az opt in / opt out vonalra.
A push 2026 ban nem 'hívd fel a usert' csatorna, hanem state szinkron és deep link a megfelelő bejövő kontextushoz. Ha minden push ad valami konkrét következő lépést (rendelés státusz, fizetési visszaigazolás, kollégai válasz, lejárati emlékeztető), az opt in természetesen 50 százalék fölött marad. Ha 'akciónk van!' jellegű, lemondsz az egész csatornáról 6 hónap alatt.

Alapító, DField Solutions
Pénzügyi cégeknél és kreátor-eszközöknél is építettem már olyan rendszereket, amik nap mint nap élesben futnak. Budapesttől San Franciscóig · startupoknak és nagyobb vállalatoknak egyaránt.
Beszéljünk a projektedről. 30 perc, nincs kötelezettség.