---
title: "Mobil push értesítések 2026 ban · iOS és Android playbook magyar appokra"
description: "APNs, FCM, opt in stratégia, szegmentálás, deep link kezelés. Mit építünk push rendszerbe egy magyar mobil app live re vitelekor 2026 ban."
date: 2026-04-26
updated: 2026-04-26
author: "Mező Dezső"
tags: "Mobile, Push, APNs, FCM, iOS, Android, deep-link"
slug: mobile-push-ertesitesek-2026
canonical: https://dfieldsolutions.hu/blog/mobile-push-ertesitesek-2026
---

# 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.
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).

> **NOTE:** 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.

## 1. iOS opt in · a magyar piacon konkrét számok

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.

## 2. Android 13+ runtime permission

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.

```kotlin
// 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)
  }
}
```

## 3. APNs · token rotáció a leggyakoribb fejtörés

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.

```swift
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
    )
  }
}
```

> **WARN:** 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.

## 4. FCM v1 · ha még legacy HTTP n vagy, ki kell jönnöd

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.

```ts
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)}`);
  }
}
```

## 5. Szegmentálás · a magyar nyelv és időzóna

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').

## 6. Deep link · a tipikus elveszett konverzió

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.

```json
{
  "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"
        }
      }
    }
  }
}
```

## 7. Kvóta és cost · a magyar 50 ezer felhasználós app esetén

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.

> **TIP:** 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.

## Záró gondolat

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.

---

Source: https://dfieldsolutions.hu/blog/mobile-push-ertesitesek-2026
Author: Mező Dezső · Alapító, DField Solutions
Site: https://dfieldsolutions.hu