Control showing of notifications on iOS by rajveermalviya · Pull Request #2156 · zulip/zulip-flutter

rajveermalviya · 2026-02-18T16:59:39Z

Testing

iOS Notification Service doesn't execute unless the push notification has the "mutable-content" : 1 property under "aps" object.

Zulip server doesn't set this property in non-e2ee push notifications, so the dev server will need the patch below to do the testing:

diff --git a/zerver/lib/push_notifications.py b/zerver/lib/push_notifications.py
index 4f9f0de5ae..f6da5c12fb 100644
--- a/zerver/lib/push_notifications.py
+++ b/zerver/lib/push_notifications.py
@@ -323,6 +323,7 @@ def send_apple_push_notification(
             num_duplicate_tokens,
         )
     payload_data = dict(payload_data)
+    payload_data["mutable-content"] = 1
     message = {**payload_data.pop("custom", {}), "aps": payload_data}
 
     have_missing_app_id = False

Additionally, the iOS Notification Service doesn't execute with the simulated push notifications as described in "Testing Push Notifications on iOS Simulator" docs. It only executes if the push notification is a real push notification either from the Sandbox/Production APNs server. So, the dev server will need to setup those as documented here.

Fixes: #1265

rajveermalviya · 2026-02-25T17:38:51Z

This is ready for review now!

rajveermalviya · 2026-02-26T19:00:27Z

In the pariring call today, Greg metioned that there are some commits here that could be squashed — I'll do that tommorow. (Namely: swift-format into swift code changes, flutter build ios --config-only into the commits that require them, and some steps from the guide could be merged).

chrisbobbe

Thanks, this is exciting!! Comments below, from reading the commits. I haven't yet done manual testing.

chrisbobbe · 2026-02-27T06:30:53Z

ios/NotificationService/Info.plist

+		<key>NSExtensionPointIdentifier</key>
+		<string>com.apple.usernotifications.service</string>
+		<key>NSExtensionPrincipalClass</key>
+		<string>$(PRODUCT_MODULE_NAME).NotificationService</string>


ios: Add Notification service app extension target via Xcode

Commit-message nit: I think you mean "NotificationService" or "notification service", not "Notification service"? Depending on whether or not you want to refer to the specific name that appears in the code.

chrisbobbe · 2026-02-27T06:35:13Z

ios/NotificationService/NotificationService.swift

+//  NotificationService.swift
+//  NotificationService
+//
+//  Created by Rajesh Malviya on 18/02/26.


chrisbobbe · 2026-02-27T06:41:49Z

ios/Runner.xcodeproj/project.pbxproj

 				INFOPLIST_KEY_CFBundleDisplayName = NotificationService;
 				INFOPLIST_KEY_NSHumanReadableCopyright = "";
-				IPHONEOS_DEPLOYMENT_TARGET = 26.2;
+				IPHONEOS_DEPLOYMENT_TARGET = 15.0;


The "iOS Deployment Target" of "Runner" is something we mention in a comment at the top of ios/Podfile:

# This should match the iOS Deployment Target # (in Xcode, that's in project > Runner > Info) # and MinimumOSVersion in ios/Flutter/AppFrameworkInfo.plist. platform :ios, '15.0'

Should that comment grow a mention of this new thing that needs to be set to the same value? I believe this is where we declare the minimum supported iOS version, so it's definitely something we expect to change in the future.

chrisbobbe · 2026-02-27T07:01:45Z

ios/Runner.xcodeproj/project.pbxproj

+			);
+			runOnlyForDeploymentPostprocessing = 0;
+			shellPath = /bin/sh;
+			shellScript = "/bin/sh \"$FLUTTER_ROOT/packages/flutter_tools/bin/xcode_backend.sh\" build\n";


ios: In Xcode, add Run Script build phase for the extension target

Hmm, just above this B378A52C2F45C31A0031EFA1 /* ShellScript */ = { block is a nearly identical block 9740EEB61CF901F6004384FC /* Run Script */ = { which has the same shellScript value. Are they both needed? I wonder if the problem was just that the old way of expressing the desired build phase wasn't working.

The previous 9740EEB61CF901F6004384FC /* Run Script */ block is referenced by the Runner target, and B378A52C2F45C31A0031EFA1 /* ShellScript */ is being added by this workaround/step for the NotificationService target (Not sure why the (commented) name generated here is different, in Xcode both phases, under TARGETS > [Runner/NotificationService] > Build Phases (tab) > Run Script, are called "Run Script".

chrisbobbe · 2026-02-27T07:06:26Z

lib/notifications/ios_service.dart

+// `assert()` statements are not working in the extension even when running in
+// the debug mode. But fortunately `kDebugMode` does correctly return true in
+// the debug mode and false in the release mode. So, use this helper instead of
+// `debugLog` from `log.dart`.


Maybe worth a // TODO debug asserts not working on this.

chrisbobbe · 2026-02-27T07:16:39Z

ios/NotificationService/NotificationService.swift

+    // current thread is being polled by the system. Which is not the case in
+    // Notification Service Extension, so here we manually poll the event loop.
+    // See discussion:
+    //   https://chat.zulip.org/#narrow/channel/243-mobile-team/topic/Running.20Dart.20code.20in.20iOS.20Notification.20Service.20Extension/with/2370721


Will there be a change to be made here if a PR like flutter/flutter#181645 lands? If so, let's add a TODO. (I'm not familiar with all the details but I found that PR by following links.)

chrisbobbe · 2026-02-27T07:21:35Z

lib/main.dart

+// This library defines the Dart entrypoint function for headless FlutterEngine
+// used in iOS Notification Service Extension. We need to import it here to
+// avoid it being treeshaked during build process.
+// ignore: unused_import
+import 'notifications/ios_service.dart';


I wonder if this is the standard way to prevent something from being treeshaken, or if there's some config in the build process for this?

I believe @pragma('vm:entry-point') decorator prevents the top-level function from being tree-shaked but AIUI there's no way to prevent the whole unimported dart library from being tree-shaked. (I realize tree-shaked is not the correct term, it's more that the dart library is not imported anywhere so it's not included in the build.)

chrisbobbe · 2026-02-27T07:24:14Z

ios/NotificationService/NotificationService.swift

+    guard let bestAttemptContent = bestAttemptContent else {
+      return
+    }


What is this early return doing? I'm not sure if this needs a comment or if I just need to learn more Swift. 🙂

chrisbobbe · 2026-02-27T07:27:04Z

ios/NotificationService/NotificationService.swift

+      switch result {
+      case .success(let mutatedNotificationContent):
+        os_log("didReceivePushNotification: success")
+        bestAttemptContent.title = mutatedNotificationContent.title
+        if let body = mutatedNotificationContent.body {
+          bestAttemptContent.body = body
+        }
+        contentHandler(bestAttemptContent)
+
+      case .failure(let error):
+        os_log("didReceivePushNotification: failed: error=\(error.localizedDescription)")
+        contentHandler(bestAttemptContent)
+      }
+    }


Again, this switch/case indentation looks odd to me.

See: #2156 (comment)

chrisbobbe · 2026-02-27T07:34:25Z

pigeon/ios_notifications.dart

+  final Map<Object?, Object?> payload;
+}
+
+class MutatedNotificationContent {


I wonder if "mutated" is the name we want here, or if there's something more specific we want to emphasize? The goal is to make "better"/"improved" notification content, right, not just different/changed content. 😛 #1265 says "improve the wording and formatting of notifications".

I had used MutatedNotificationContent name to correspond to UNMutableNotificationContent. Changed to "ImprovedNotificationContent".

chrisbobbe

And some more comments, including ones on the last commit, which I forgot to read last time around (oops).

chrisbobbe · 2026-02-28T02:08:21Z

lib/model/binding.dart

  Future<void> toggleWakelock({required bool enable});
+
+  /// The iOS App Group identifier specified in the Xcode config.
+  static const iosAppGroupIdentifier = 'group.zulip.test';


This will eventually not say "test", right? Do we need a comment on the consequences of changing this in future (e.g. data loss?)

chrisbobbe · 2026-02-28T02:19:44Z

test/notifications/ios_service_test.dart

+
+  IosNotifFlutterApi iosNotifFlutterApi() => TestZulipBinding.instance.iosNotifFlutterApi!;
+
+  test('smoke', () async {


This needs a addTearDown(testBinding.reset);, I think.

chrisbobbe · 2026-02-28T02:22:40Z

test/notifications/ios_service_test.dart

+  IosNotifFlutterApi iosNotifFlutterApi() => TestZulipBinding.instance.iosNotifFlutterApi!;
+
+  test('smoke', () async {
+    IosNotificationService.init();


IosNotificationService has mutable state (isExecutingInExtension) which we don't want to leak between tests; probably it should have a reset method that tests call on teardown?

chrisbobbe · 2026-02-28T02:28:05Z

lib/model/store.dart


  /// The file path to use for the app database.
  static Future<File> _dbFile() async {
+    if (defaultTargetPlatform == TargetPlatform.iOS) return _maybeCopyIosDbFile();


Below this new early return, the comment starting with "What directory should we use?" now looks confusing:

It's a long comment, so it seems like the question it's asking doesn't have a simple answer.

…But the question has apparently been answered anyway, at least for iOS.

The answer still includes "on iOS" cases.

chrisbobbe · 2026-02-28T02:47:57Z

lib/model/store.dart

+    if (IosNotificationService.isExecutingInExtension) {
+      // In iOS Notification Service Extension we can't copy the file, as the
+      // extension will not have access to main app target's filesystem.
+      // We also can't return the App Group container path here when running in
+      // the extension, because it will cause creation of new empty DB file,
+      // which then the main app target will prefer because of the code above.
+      // So, abort if we are running in iOS Notification Service Extension and
+      // the database is not already migrated to the App Group container.
+      throw Exception('The database file in iOS app group container doesn\'t '
+        'exists, and when running in iOS Notification Service Extension the '
+        'database file can\'t be migrated');
+    }


I think some of this comment and error message can be removed/simplified if we make the dartdoc more explicit about why the things it does are needed.

Can we make the dartdoc clear that

This is essentially a one-time migration that enables the extension to work. The extension won't work without it because [etc.].

The migration can only be run by the app, not the app extension, because [etc.].

If this runs in the app extension before the migration has been done, [etc.] happens.

This reminds me of the data migration from the legacy app, right? Though less complex, because we're just straightforwardly copying a file instead of restructuring data and so on. Still, are there details from that former migration that would be helpful to think about here? (Like how to organize the code?) Do we need to set a flag somewhere tracking whether the migration is complete, like we do for other migrations? Would some test coverage be feasible? Etc. It would be embarrassing to cause data loss for people by mishandling a migration somehow. 🙂

Added the required context to the dartdoc.

Do we need to set a flag somewhere tracking whether the migration is complete, like we do for other migrations?

I don't think this is needed because it is only a single operation (copying the file), and would only be executed from Runner target, so no race condition between Runner and NotificationService.

Would some test coverage be feasible

Not sure how best to unit test this type of file copy migrations, if we did mocks for file system api that it would not really be testing actual code.

It would be embarrassing to cause data loss for people by mishandling a migration somehow.

Agreed.

chrisbobbe · 2026-02-28T02:53:51Z

lib/model/store.dart

+                      'to iOS app group container path: $containerDbFile'));
+      await nonContainerDbFile.copy(containerDbFile.path);
+
+      // TODO do we want to delete nonContainerDbFile here?


This seems like the kind of detail that we'd want to have a plan for, even if we don't do it right now, before merging this migration.

gnprice

Thanks! Here's a handful of comments from an initial skim. (I realize this hasn't been marked as fully revised for Chris's comments above.)

gnprice · 2026-03-04T23:43:52Z

ios/NotificationService/IosNotifications.g.swift

@@ -0,0 +1,239 @@
+// Autogenerated from Pigeon (v26.1.7), do not edit directly.


This new generated file should be added to .gitattributes so that it gets collapsed in git diff.

(Better: a pattern that covers it and similar files.)

gnprice · 2026-03-04T23:46:13Z

lib/model/store.dart

+    // TODO rename the group identifier.
+    const iosAppGroupIdentifier = 'group.zulip.test';


Maybe group.zulip.app? Seems like this group is basically "the Zulip app, as a whole".

gnprice · 2026-03-04T23:52:05Z

lib/model/store.dart

+    if (defaultTargetPlatform == TargetPlatform.iOS) {
+      file = await _maybeCopyIosDbFile();
+    } else {
+      file = await _dbFile();


This complication seems like something that's not part of this caller's job to worry about. It should go inside the method this code is calling, so either _dbFile or some new method.

gnprice · 2026-03-04T23:55:19Z

lib/model/store.dart

+        'database file can\'t be migrated');
+    }
+
+    final nonContainerDbFile = await _dbFile();


Echoing and expanding a bit on what Chris said at #2156 (comment) : definitely take the code in _dbFile as open to revision with the changes you're making here. The filename that the existing logic there produces is no longer really "the DB file" for the app on iOS; so either the method's name, or its logic, or both, should change. Likely the comment in it should then change too. The goal is for the new code after your changes to have a logic and structure that's clear to the reader, even without them having seen what the code looked like previously.

rajveermalviya · 2026-03-05T15:50:05Z

Thanks for the reviews @chrisbobbe, @gnprice! Pushed a new revision, PTAL.

chrisbobbe · 2026-03-06T01:38:04Z

Would you try the following:

In step 4 of https://docs.flutter.dev/platform-integration/ios/app-extensions#creating-app-extension-uis-with-flutter we should add the script pre-action to the "Runner" scheme (the scheme we always use) instead of the auto-generated "NotificationService" scheme.
Remove the workaround script phase that we added to the "NotificationService" target's build phases.

Possibly that step 4 should be changed. It seems odd to add the pre-action only on the scheme dedicated to building the app extension in isolation. In our case, at least, I think we can just delete that (the auto-generated "NotificationService" scheme)… Our default scheme, "Runner", which has become a confusing name, builds both the "Runner" target and the "NotificationService" target, which is probably always what we want.

The goal is to avoid running the heavier xcode_backend.sh build command (which runs flutter assemble) twice. This should cause the lightweight xcode_backend.sh prepare command to run once, instead; that will just copy the Flutter framework to a place where Xcode will find it when building the NotificationService target, meeting the need discussed at flutter/flutter#103344 (comment).

See flutter/flutter#146256 (which is basically the same solution to this problem as it appears in a different context):

In addition, a "Pre-action" script will be added via altering of the Runner.xcscheme. This script will invoke the flutter tool to copy the Flutter/FlutterMacOS framework to the BUILT_PRODUCTS_DIR directory before the build starts. This is needed because plugins need to be linked to the Flutter framework and fortunately Swift Package Manager automatically uses BUILT_PRODUCTS_DIR as a framework search path.

chrisbobbe · 2026-03-06T02:29:52Z

If that works, then try reverting step 3 of https://docs.flutter.dev/platform-integration/ios/app-extensions#creating-app-extension-uis-with-flutter :

In Xcode, disable user script sandboxing

That seems to be a security feature that applies to script build phases: you limit the script's permissions to specific input and output files. But the instructions don't ask you to add a script build phase, and if my suggestion above worked, you won't have added any.

I don't think there's a version of this feature that applies to a pre-action script. In the UI to configure a pre-action script, there's no way to specify input/output files.

chrisbobbe · 2026-03-06T03:12:08Z

For step 5 of https://docs.flutter.dev/platform-integration/ios/app-extensions#creating-app-extension-uis-with-flutter:

In Xcode, share the build configurations.

would you make a separate commit for that (or maybe squash it into the commit that creates the new target)? It's an interesting change because:

it can help us simplify our min-iOS-version config (I'll explain in a separate comment)
it pulls in some build config specified by Flutter, including some CocoaPods-related stuff; see for example ios/Flutter/Release.xcconfig :

#include? "Pods/Target Support Files/Pods-Runner/Pods-Runner.release.xcconfig"
#include "Generated.xcconfig"
#include "Zulip.xcconfig"

Probably the app extension's Flutter behavior depends on some of that config. But we might find out later that these defaults aren't a perfect fit for app extensions; it won't be top-of-mind when Flutter makes changes to it.

chrisbobbe · 2026-03-06T03:23:18Z

ios/Flutter/Debug.xcconfig and ios/Flutter/Release.xcconfig both import ios/Flutter/Zulip.xcconfig. We should be able to set IPHONEOS_DEPLOYMENT_TARGET with one line in Zulip.xcconfig and have it flow to all of our targets, as long as all of the targets share ios/Flutter/Debug.xcconfig and ios/Flutter/Release.xcconfig. This is what you ensured for the NotificationService target in that step 5 "share the build configurations" that I mentioned in my previous comment. Then we should be able to delete all references to IPHONEOS_DEPLOYMENT_TARGET in project.pbxproj and delete all the instructions at the top of ios/Podfile about navigating the Xcode GUI. 🎉

This moves IPHONEOS_DEPLOYMENT_TARGET config to Zulip.xcconfig, instead of it being specified for different Xcode config sections. This vastly simplifies changing the iOS deployment target later, allowing us to change a single variable, instead of navigating through the Xcode UI to change for multiple targets (two currently; Runner and RunnerTests). See: zulip#2156 (comment)

This carries out the steps 3-4 from guide for "Add iOS app extension" section in the docs: https://docs.flutter.dev/platform-integration/ios/app-extensions#add-extension Then ran 'swift-format' over the generated Swift code. (In the Xcode menu bar, Editor -> Structure -> Format file with 'swift-format'.) Finally, this also carries out step 5 from "Open a Flutter app in an iOS app extension" section in the docs: https://docs.flutter.dev/platform-integration/ios/app-extensions#creating-app-extension-uis-with-flutter which shares the build configurations between extension target and Runner target. Allowing the extension target to: - Inherit the IPHONEOS_DEPLOYMENT_TARGET config value, from Zulip.xcconfig which {Debug,Release}.xcconfig imports. - Also it pulls in some build config specified by Flutter, including some CocoaPods-related stuff; see for example ios/Flutter/Release.xcconfig. See: zulip#2156 (comment)

…xtension Implement initial setup for headless FlutterEngine for running Dart code in NotificationService extension. This carries out the step 5 from guide for "Open a Flutter app in an iOS app extension" section in the docs: https://docs.flutter.dev/platform-integration/ios/app-extensions#creating-app-extension-uis-with-flutter This carries out the steps 2-3 from guide for "Register plugins" section in the docs: https://docs.flutter.dev/platform-integration/ios/app-extensions#register-plugins Additionally adds the following pre-action script for the Runner scheme: /bin/sh "$FLUTTER_ROOT/packages/flutter_tools/bin/xcode_backend.sh" prepare This script copies the Flutter framework to a place where Xcode will find it when building the NotificationService target. See discussion: zulip#2156 (comment)

Fixes most of zulip#1764, namely for Android. Fixes zulip#322. This will cause the app to start receiving and displaying end-to-end encrypted notifications (zulip#1764), on Android, when the server is new enough to support the feature. The new protocol also fixes zulip#322, deduping sending the token to the server, by design. This commit also stops showing any notifications we receive over the legacy plaintext protocol when E2EE notifications are supported. This avoids duplicates. It potentially causes a brief interruption in getting notifications when either client or server is first upgraded to support the new protocol. The remaining required piece before zulip#1764 is complete is to implement it on iOS too. I believe that will be a fairly straightforward extension of this change (and all the changes that led up to it) together with zulip#2156, which gives us control over iOS notifications in the first place (zulip#1265).

gnprice · 2026-03-12T01:47:31Z

ios/Flutter/Zulip.xcconfig

+// TODO change group name
+ZULIP_APP_GROUP_IDENTIFIER=group.zulip.test


I've just registered a group group.com.zulip.app (much like we were saying on a call last week). Let's use that.

gnprice

Thanks @rajveermalviya for building this, and @chrisbobbe for the detailed previous reviews! Here's a round of comments. I've read the first 5 commits:
386b162 ios [nfc]: Extract setting IPHONEOS_DEPLOYMENT_TARGET to Zulip.xcconfig
f19211b ios [nfc]: Extract setting DEVELOPMENT_TEAM to Zulip.xcconfig
c2b04af ios [nfc]: In Xcode, run swift-format
2379cba ios: Add NotificationService app extension target via Xcode
18cc590 notif ios: Initialize headless FlutterEngine in NotificationService extension

Still ahead are the remaining 3 commits:
62c1bcd ios: Implement ability to intercept APNs push notifications from Dart
4a31bbc TODO(group name) ios: Add both Runner and extension target to the same App Group
440e2e6 store ios: Migrate database file to iOS App Group container path

gnprice · 2026-03-12T22:59:56Z

ios/NotificationService/NotificationService.swift

+import Flutter
+import UserNotifications
+
+class NotificationService: UNNotificationServiceExtension {


The commit message says:

This carries out the steps 3-4 from guide for "Add iOS app extension" section in the docs: https://docs.flutter.dev/platform-integration/ios/app-extensions#add-extension

Those instructions call for a "Share Extension", though. This was presumably from a variation choosing "Notification Service Extension".

gnprice · 2026-03-12T23:04:15Z

ios/NotificationService/NotificationService.swift

+  override func didReceive(
+    _ request: UNNotificationRequest,
+    withContentHandler contentHandler: @escaping (UNNotificationContent) -> Void
+  ) {


Then ran 'swift-format' over the generated Swift code. (In the Xcode menu bar, Editor -> Structure -> Format file with 'swift-format'.)

When I try this, it formats everything at 4-space indents. (Which also causes this parameter's declaration to wrap onto two lines.) Is there a setting somewhere that controls that? Can we check that into the repo so it's shared?

gnprice · 2026-03-12T23:20:33Z

ios/Runner.xcodeproj/project.pbxproj

+				CURRENT_PROJECT_VERSION = "$(FLUTTER_BUILD_NUMBER)";
+				ENABLE_USER_SCRIPT_SANDBOXING = YES;
+				GCC_C_LANGUAGE_STANDARD = gnu17;
+				GENERATE_INFOPLIST_FILE = YES;
+				INFOPLIST_FILE = NotificationService/Info.plist;
+				INFOPLIST_KEY_CFBundleDisplayName = NotificationService;
+				INFOPLIST_KEY_NSHumanReadableCopyright = "";
+				LD_RUNPATH_SEARCH_PATHS = (
+					"$(inherited)",
+					"@executable_path/Frameworks",
+					"@executable_path/../../Frameworks",
+				);
+				LOCALIZATION_PREFERS_STRING_CATALOGS = YES;
+				MARKETING_VERSION = "$(FLUTTER_BUILD_NAME)";


When I try reproducing the steps in this commit message:
2379cba ios: Add NotificationService app extension target via Xcode

I get some lines different here, including:

CURRENT_PROJECT_VERSION = 1; IPHONEOS_DEPLOYMENT_TARGET = 18.2; MARKETING_VERSION = 1.0;

I see some discussion in the thread above about fixing two of those to be $(FLUTTER_BUILD_NUMBER) and $(FLUTTER_BUILD_NAME) and the third to be absent (and implicitly inherited). All those fixes sound good to me. Did you do them by clicking around somewhere in the Xcode GUI, or something else?

Even if it's just "I clicked around in the Xcode GUI to adjust these", that fact would be helpful to mention in the commit message, with these three names of variables you adjusted. Since the values you chose are here in the diff, that's enough for someone to reproduce a similar change in the future — for example, for one of us to follow when adding a ShareExtension, when we go to implement that feature.

gnprice · 2026-03-12T23:22:41Z

ios/NotificationService/NotificationService.swift

+    // Modify the notification content here...
+


This comment was in the template that Xcode used for this file. It's useful in that context as a guide to someone beginning to write the extension. Now that you've written the extension, though, it doesn't seem helpful: the code below does the modifying.

gnprice · 2026-03-12T23:32:16Z

ios/Runner.xcodeproj/xcshareddata/xcschemes/Runner.xcscheme

   <BuildAction
      parallelizeBuildables = "YES"
      buildImplicitDependencies = "YES">
+      <PreActions>


The commit message says:

Additionally adds the following pre-action script for the Runner scheme: /bin/sh "$FLUTTER_ROOT/packages/flutter_tools/bin/xcode_backend.sh" prepare This script copies the Flutter framework to a place where Xcode will find it when building the NotificationService target. See discussion: https://github.com/zulip/zulip-flutter/pull/2156#issuecomment-4008936845

This is somewhat mysterious about just how one goes about adding a pre-action script to a scheme, though. It also doesn't make clear what prompted us to take such a step.

After following the link and reading there, I think the key points here are:

We're doing step 4 of https://docs.flutter.dev/platform-integration/ios/app-extensions#creating-app-extension-uis-with-flutter .

But we're doing a variation that's cleaner: instead of adding it to the new extension's scheme, we're adding to the main Runner scheme.

See that comment for discussion.

gnprice · 2026-03-13T00:10:13Z

lib/notifications/ios_service.dart

+    final iosNotifFlutterApiImpl = _IosNotifFlutterApiImpl();
+    ZulipBinding.instance.setupIosNotifFlutterApi(iosNotifFlutterApiImpl);


nit: inline

gnprice · 2026-03-13T00:10:23Z

lib/notifications/ios_service.dart

+    return ImprovedNotificationContent(
+      title: parsed.title,
+      body: parsed.body);


nit: one line

gnprice · 2026-03-13T00:11:15Z

lib/notifications/ios_service.dart

+// debug mode. But fortunately `kDebugMode` does correctly return true in debug
+// mode and false in the release mode. So, use this helper instead of
+// `debugLog` from `log.dart`.
+// TODO debug asserts not working


Let's mark that this is presumably some sort of upstream issue:

Suggested change

// TODO debug asserts not working

// TODO(upstream) debug asserts not working

gnprice · 2026-03-13T00:11:23Z

lib/notifications/ios_service.dart

+
+@pragma('vm:entry-point')
+void iosNotificationServiceMain() {
+  WidgetsFlutterBinding.ensureInitialized();


Let's have this explicitly do nothing outside iOS, something like this:

Suggested change

WidgetsFlutterBinding.ensureInitialized();

void iosNotificationServiceMain() {

if (defaultTargetPlatform != TargetPlatform.ios) throw Error();

WidgetsFlutterBinding.ensureInitialized();

That way the Android build can tree-shake everything downstream of this.

(In principle the effect we want here is to make the @pragma('vm:entry-point') conditional on iOS, because the truth is that this will only be an entry point from the VM on iOS. There's no mechanism to express that for annotations, though, at least not an obvious simple one. So we can express a similar point this way instead.)

gnprice · 2026-03-13T00:15:44Z

lib/notifications/ios_service.dart

+// `assert()` statements are not working in the extension even when running in
+// debug mode. But fortunately `kDebugMode` does correctly return true in debug
+// mode and false in the release mode. So, use this helper instead of
+// `debugLog` from `log.dart`.


nit: "in release mode", similarly to #2156 (comment)

This moves IPHONEOS_DEPLOYMENT_TARGET config to Zulip.xcconfig, instead of it being specified for different Xcode config sections. This vastly simplifies changing the iOS deployment target later, allowing us to change a single variable, instead of navigating through the Xcode UI to change for multiple targets (two currently; Runner and RunnerTests). See: zulip#2156 (comment)

Similar to previous commit, this moves DEVELOPMENT_TEAM config to Zulip.xcconfig, instead of it being specified for different Xcode config sections.

In the Xcode menu bar, Editor -> Structure -> Format file with 'swift-format'.

Carries out the steps 3-4 from "Add iOS app extension" section in the Flutter docs: https://docs.flutter.dev/platform-integration/ios/app-extensions#add-extension In step 3, the Flutter docs walk through adding a "Share Extension" target, we instead add a "Notification Service Extension" target, as described in Apple's documentation: https://developer.apple.com/documentation/usernotifications/modifying-content-in-newly-delivered-notifications#Add-a-service-app-extension-to-your-project The Swift file generated in step 3 was formatted using `swift-format` (In Xcode menu bar, Editor -> Structure -> Format file with 'swift-format'). Also carries out step 5 from the "Open a Flutter app in an iOS app extension" section in the Flutter docs: https://docs.flutter.dev/platform-integration/ios/app-extensions#creating-app-extension-uis-with-flutter this will share the build configurations between the extension target and the Runner target, allowing the extension target to: - Inherit the IPHONEOS_DEPLOYMENT_TARGET config value, from Zulip.xcconfig which {Debug,Release}.xcconfig imports. - Also it pulls in some build config specified by Flutter, including some CocoaPods-related stuff; see for example ios/Flutter/Release.xcconfig. See discussion: zulip#2156 (comment) Also made following other changes to Xcode build settings for the generated NotificationService target: - Deleted "iOS Deployment Target" config specified for target, so that when building the target, the inherited value from Zulip.xcconfig will be used. By navigating to project navigator (View > Navigators > Project) > NotificationService under TARGETS > Build Settings (tab) > Deployment, then pressed the Delete key on keyboard after selecting "iOS Deployment Target". - Updated the versioning information to match the Runner target. By navigating to project navigator (View > Navigators > Project) > NotificationService under TARGETS > Build Settings (tab) > Versioning, and changing the following values: * Changed "Current Project Version" to "$(FLUTTER_BUILD_NUMBER)" (in Xcode text field, typed without the double-quotes), where the generated value was "1". * Changed "Marketing Version" to "$(FLUTTER_BUILD_NAME)" (same as previous one, no double-quotes), where the default value was "1.0". * Changed "Versioning System" to "Apple Generic", where the default was set to "None". See discussion: zulip#2156 (comment)

…xtension Implement initial setup of a headless FlutterEngine for running Dart code in the NotificationService extension. This involves some Swift code to start the engine and drive its event loop, and a trivial Dart function to serve as the entry point. It also involves some build setup. For the build setup, this carries out the steps 2-3 from the "Register plugins" section in Flutter's guide to iOS app extensions: https://docs.flutter.dev/platform-integration/ios/app-extensions#register-plugins and adds the following pre-action script for the Runner scheme: /bin/sh "$FLUTTER_ROOT/packages/flutter_tools/bin/xcode_backend.sh" prepare That script copies the Flutter framework to a place where Xcode will find it when building the NotificationService target. See discussion: zulip#2156 (comment)

…xtension Implement initial setup of a headless FlutterEngine for running Dart code in the NotificationService extension. This involves some Swift code to start the engine and drive its event loop, and a trivial Dart function to serve as the entry point. It also involves some build setup. For the build setup, this carries out the steps 2-3 from the "Register plugins" section in Flutter's guide to iOS app extensions: https://docs.flutter.dev/platform-integration/ios/app-extensions#register-plugins and adds the following pre-action script for the Runner scheme: /bin/sh "$FLUTTER_ROOT/packages/flutter_tools/bin/xcode_backend.sh" prepare by following same steps listed under step 4 in "Open a Flutter app in an iOS app extension" section in Flutter's guide to iOS app extensions: https://docs.flutter.dev/platform-integration/ios/app-extensions#creating-app-extension-uis-with-flutter but for the Runner scheme instead of the extension scheme. And also selected the Runner target instead of the extension target for the "Provide build settings" drop-down list. That script copies the Flutter framework to a place where Xcode will find it when building the NotificationService target. See discussion: zulip#2156 (comment)

rajveermalviya · 2026-03-17T14:28:37Z

Thanks for the review @gnprice! Pushed an update, PTAL.

gnprice

Thanks for the revision! This all looks good, except one comment below. And then I still have to read those last 3 commits:
0982024 ios: Implement ability to intercept APNs push notifications from Dart
36fa1fb ios: Add both Runner and NotificationService target to the same app group
314283a store ios: Migrate database file to iOS App Group container path

gnprice · 2026-03-17T17:28:29Z

ios/Runner.xcodeproj/project.pbxproj

+				CODE_SIGN_ENTITLEMENTS = NotificationService/NotificationService.entitlements;
+				CODE_SIGN_STYLE = Automatic;
+				CURRENT_PROJECT_VERSION = "$(FLUTTER_BUILD_NUMBER)";
+				ENABLE_USER_SCRIPT_SANDBOXING = YES;


…xtension Implement initial setup of a headless FlutterEngine for running Dart code in the NotificationService extension. This involves some Swift code to start the engine and drive its event loop, and a trivial Dart function to serve as the entry point. It also involves some build setup. For the build setup, this carries out the steps 2-3 from the "Register plugins" section in Flutter's guide to iOS app extensions: https://docs.flutter.dev/platform-integration/ios/app-extensions#register-plugins and adds the following pre-action script for the Runner scheme: /bin/sh "$FLUTTER_ROOT/packages/flutter_tools/bin/xcode_backend.sh" prepare by following same steps listed under step 4 in "Open a Flutter app in an iOS app extension" section in Flutter's guide to iOS app extensions: https://docs.flutter.dev/platform-integration/ios/app-extensions#creating-app-extension-uis-with-flutter but for the Runner scheme instead of the extension scheme. And also selected the Runner target instead of the extension target for the "Provide build settings" drop-down list. That script copies the Flutter framework to a place where Xcode will find it when building the NotificationService target. See discussion: zulip#2156 (comment) We are skipping the step 3 of "Open a Flutter app in an iOS app extension": https://docs.flutter.dev/platform-integration/ios/app-extensions#creating-app-extension-uis-with-flutter because disabling user script sandboxing is only needed if we had added a "Run Script" build phase without specifying input and output files. It seems it is unnecessary for the pre-action script because Xcode UI for adding the script doesn't have the options for specifying input and output files. See discussion: zulip#2156 (comment)

Fixes zulip#1265. This uses Pigeons's handy `@FlutterApi` API to define an interface method that allows passing arguments from Swift to Dart and also get a return value back from Dart to Swift.

…roup This is required to share any files like database between both app (Runner) and the service extension targets.

This will allow the Dart code executing in the notification service extension to access the same database file as the main app target.

rajveermalviya · 2026-03-23T15:21:55Z

Updated the commit message for 6938dbd notif ios: Initialize headless FlutterEngine in NotificationService extension to include the brief about #2156 (comment).

Fixes most of zulip#1764, namely for Android. Fixes zulip#322. This will cause the app to start receiving and displaying end-to-end encrypted notifications (zulip#1764), on Android, when the server is new enough to support the feature. The new protocol also fixes zulip#322, deduping sending the token to the server, by design. This commit also stops showing any notifications we receive over the legacy plaintext protocol when E2EE notifications are supported. This avoids duplicates. It potentially causes a brief interruption in getting notifications when either client or server is first upgraded to support the new protocol. The remaining required piece before zulip#1764 is complete is to implement it on iOS too. I believe that will be a fairly straightforward extension of this change (and all the changes that led up to it) together with zulip#2156, which gives us control over iOS notifications in the first place (zulip#1265).

gnprice

OK, and here's a review of the main commit:
9265eaf ios: Implement ability to intercept APNs push notifications from Dart

Still up for me to read:
f034f9b ios: Add both Runner and NotificationService target to the same app group
a857dcd store ios: Migrate database file to iOS App Group container path

gnprice · 2026-03-27T00:46:28Z

ios/NotificationService/NotificationService.swift

+    // Adapted from: https://github.com/flutter/flutter/blob/65b1ec407/engine/src/flutter/fml/platform/darwin/message_loop_darwin.mm#L44-L62
+    let kDistantFuture = 1.0e10
+    while loopRunning {
+      let result = CFRunLoopRunInMode(.defaultMode, kDistantFuture, true)
+      if result == .stopped || result == .finished {
+        loopRunning = false
+      }
+    }


Why does this loop get revised to a different form in this commit:
9265eaf ios: Implement ability to intercept APNs push notifications from Dart

after being introduced in this commit?
6938dbd notif ios: Initialize headless FlutterEngine in NotificationService extension

It looks like there are a couple of substantive changes in behavior in that revision, too:

a result of .timedOut would stop the loop in the initial version, but continue it in the new version;

the seconds: argument is 1 in the initial version, but 1e10 in the new version.

Should the loop have the later form from the beginning? How did you determine what the right answer was for those two details? (It looks like the linked code this was adapted from matches the later form; was there a source for the initial form?)

gnprice · 2026-03-27T00:48:34Z

lib/notifications/ios_service.dart

+class IosNotificationService {
+  const IosNotificationService._();
+


nit: since the point is that this never gets instantiated, make that more explicit with abstract class:

Suggested change

class IosNotificationService {

const IosNotificationService._();

abstract class IosNotificationService {

gnprice · 2026-03-27T02:21:25Z

lib/notifications/ios_service.dart

+      final body = alertData['body'] as String?;
+      return _ApnsPayload._(title: title, body: body);


This doesn't end up having any visible effect, right? It just sets the title and body to what they already were.

That's fine for completing #1265, and as an intermediate state toward #1764 and the other things that #1265 enables. But it's kind of confusing when reading this code, because it's a whole lot of apparatus that turns out to (currently) do nothing. So let's make it explicit with a comment.

gnprice · 2026-03-27T02:27:05Z

lib/notifications/ios_service.dart

+  factory _ApnsPayload.parseApnsPayload(Map<Object?, Object?> payload) {
+    if (payload case {
+      "aps": {
+        "alert": {
+          "title": final String title,
+        } && final alertData,
+      },
+    }) {
+      final body = alertData['body'] as String?;


I don't love this way of parsing. The payload here is JSON; our normal way of parsing JSON is with package:json_serializable, and I think that works out more cleanly. (Among other things, it would naturally treat the optional body and required title in a symmetrical way.)

It seems like this whole _ApnsPayload class is basically temporary, though, as a scaffold to demonstrate #1265 which gets torn down when #2230 implements #1764. So I guess we can leave it.

gnprice · 2026-03-27T02:32:56Z

lib/notifications/ios_service.dart

+    _debugLog("dart: _IosNotifFlutterApiImpl.didReceivePushNotification");
+    _debugLog("dart: content.payload=${jsonEncode(content.payload)}");
+
+    final parsed = _ApnsPayload.parseApnsPayload(content.payload);


As long as we're doing this parsing in a throwaway fashion, though, I think we can do it more simply:

Suggested change

final parsed = _ApnsPayload.parseApnsPayload(content.payload);

final apsData = content.payload['aps'] as Map<Object?, Object?>;

final alertData = apsData['alert'] as Map<Object?, Object?>;

final title = alertData['title'] as String;

final body = alertData['body'] as String?;

I believe that behaves equivalently to the PR's current version. (It'll throw directly from the as operators if the data doesn't match, rather than FormatException. But the current version will already do that if body in particular has the wrong type.)

gnprice · 2026-03-27T02:37:38Z

lib/model/binding.dart


  Stream<android_intents_pigeon.AndroidIntentEvent> get androidIntentEvents;

+  void setupIosNotifFlutterApi(IosNotifFlutterApi api);


What does this method do; when and how should it be called?

This should get a brief bit of docs, like the other binding methods.

gnprice · 2026-03-27T02:39:36Z

test/notifications/ios_service_test.dart

+void main() {
+  TestZulipBinding.ensureInitialized();
+
+  IosNotifFlutterApi iosNotifFlutterApi() => TestZulipBinding.instance.iosNotifFlutterApi!;


nit: use the handy testBinding alias

Suggested change

IosNotifFlutterApi iosNotifFlutterApi() => TestZulipBinding.instance.iosNotifFlutterApi!;

IosNotifFlutterApi iosNotifFlutterApi() => testBinding.iosNotifFlutterApi!;

(And then do we need this method at all, or can it just as well be inlined?)

gnprice · 2026-03-27T02:41:59Z

test/notifications/ios_service_test.dart

+    IosNotificationService.init();
+    addTearDown(IosNotificationService.debugReset);


nit: add the reset teardown first

Suggested change

IosNotificationService.init();

addTearDown(IosNotificationService.debugReset);

addTearDown(IosNotificationService.debugReset);

IosNotificationService.init();

That's what most of our tests do. It's a bit more comprehensive in behaving correctly, in particular if an exception occurs for some reason within the init call.

gnprice · 2026-03-27T02:50:25Z

lib/notifications/ios_service.dart

+// `assert()` statements are not working in the extension even when running in
+// debug mode. But fortunately `kDebugMode` does correctly return true in debug
+// mode and false in release mode. So, use this helper instead of `debugLog`
+// from `log.dart`.
+// TODO(upstream) debug asserts not working
+void _debugLog(String message) {
+  if (kDebugMode) {
+    print(message);


This file's tests are noisy when run:

$ flutter test --no-pub test/notifications/ios_service_test.dart 00:02 +0: smoke dart: IosNotificationService.init dart: _IosNotifFlutterApiImpl.didReceivePushNotification dart: content.payload={"aps":{"alert":{"title":"test title","subtitle":"test","body":"test content"},"sound":"default","badge":0},"zulip":{"server":"zulip.example.cloud","realm_id":4,"realm_uri":"https://chat.example/","realm_url":"https://chat.example/","realm_name":"Test","user_id":1008,"sender_id":12345,"sender_email":"a-person@example","time":1678139636,"message_ids":[1035],"recipient_type":"stream","stream_id":123,"topic":"example topic 703"}} 00:02 +1: All tests passed!

The bulk of our code avoids that problem by using debugLog, whose behavior is controlled by a flag debugLogEnabled which is left false in tests. So this problem can be solved by adding a similar flag which is used in this file.

But I wonder now if debugLogEnabled could explain the behavior you saw that led you to introduce this function. If you have iosNotificationServiceMain set debugLogEnabled in the same way as the app's main function, and then use debugLog the same way as elsewhere, does the issue still reproduce?

gnprice

Partial review of the remaining commits below. (Going afk for now, so going ahead and posting this.)

gnprice · 2026-03-27T03:00:48Z

test/model/binding.dart

  FakeNotificationPigeonApi? _notificationPigeonApi;

+  IosNotifFlutterApi? get iosNotifFlutterApi => _iosNotifFlutterApi;
+  IosNotifFlutterApi? _iosNotifFlutterApi;


This field, like all state on the test binding, should get reset by one of the methods called by reset.

gnprice · 2026-03-27T03:03:43Z

lib/model/store.dart

+    }
+  }
+
+  static Future<String> _getIosAppGroupContainerPath() async {


nit: define entry points vs helpers in a consistent order; the surrounding methods go caller, then callee, so this should match by going after _iosDbFile rather than before

Another angle on the same point: _iosDbFile is a direct helper of _dbFile, so it's better if they can go next to each other, in order to enable reading them together. This is unrelated to _dbFile, so there's no benefit to having it separate those two from each other; it's a helper for _iosDbFile, but it can go next to that method by going after it instead of before.

gnprice · 2026-03-27T03:10:34Z

lib/model/store.dart

+    final pathProviderFoundation = PathProviderFoundation();
+    final containerDbDir = await pathProviderFoundation.getContainerPath(


nit: inline

gnprice

OK, finished reading; just a couple more comments below.

gnprice · 2026-03-30T19:56:49Z

lib/model/store.dart

+    // This group identifier is used to access the shared file system,
+    // across the different targets which are sandboxed from each other.
+    // See: https://developer.apple.com/documentation/xcode/configuring-app-groups
+    //
+    // Generally this identifier should never be changed, because doing so
+    // will reset the filesystem, causing the creation of new database from
+    // scratch.


Hmm, maybe I understand now why you initially didn't expect rename to work and were surprised to find that it did.

The app group's data doesn't live in a distinct filesystem. These comments shouldn't say "filesystem", because that has a specific meaning (see for example man mount), with implications including that rename will not work between one filesystem and another.

The Apple docs on this feature don't ever say it's a distinct filesystem:
https://developer.apple.com/documentation/xcode/configuring-app-groups
https://developer.apple.com/documentation/Foundation/FileManager/containerURL(forSecurityApplicationGroupIdentifier:)
Instead they say things like

the app group’s shared container

and even

the group’s shared directory in the file system

which specifically points toward it being in the same filesystem as other data.

The fact that rename works for moving a file from outside the shared container to inside the shared container is also definitive empirical proof that the two sides are part of the same filesystem, not distinct filesystems. That's enough to show that we shouldn't be saying in our comments that it's a separate filesystem. On that evidence alone, there's always the possibility that it's different on different iOS versions, or could be in the future; but then there's also what the docs say.

gnprice · 2026-03-30T20:16:59Z

lib/model/store.dart

+    // Move the database file from Runner target's filesystem which was stored
+    // at the directory path returned from path_provider's
+    // `getApplicationSupportDirectory` function, and it returns the following
+    // path:
+    //   "Library/Application Support" via https://developer.apple.com/documentation/foundation/nssearchpathdirectory/nsapplicationsupportdirectory
+    final nonContainerDbDir = await getApplicationSupportDirectory();


This comment recites what the code says, but doesn't say why we'd want to do this. Instead:

Suggested change

// Move the database file from Runner target's filesystem which was stored

// at the directory path returned from path_provider's

// `getApplicationSupportDirectory` function, and it returns the following

// path:

// "Library/Application Support" via https://developer.apple.com/documentation/foundation/nssearchpathdirectory/nsapplicationsupportdirectory

final nonContainerDbDir = await getApplicationSupportDirectory();

// Older versions of the app stored the database file at a different path.

// Move it from there, if present.

final nonContainerDbDir = await getApplicationSupportDirectory();

(We also don't need the details about what getApplicationSupportDirectory turns out to return. Those were relevant when choosing that function in the first place, and are arguably still relevant in _dbFile because they explain the choice that's still live there. But here it doesn't matter if this directory was a good place to choose for where the file should live; the reason we're interacting with it in these lines is because it's a place we did choose in earlier versions of the app.)

gnprice · 2026-04-03T00:03:56Z

Additionally, the iOS Notification Service doesn't execute with the simulated push notifications as described in "Testing Push Notifications on iOS Simulator" docs. It only executes if the push notification is a real push notification either from the Sandbox/Production APNs server.

Hmm, does this mean that after this PR, those instructions no longer exercise the code path that notifications normally take? And after #2230, they won't work at all for the normal kind of notification (namely E2EE notifications). In that case, they should get deleted so as not to potentially cause confusion in the future.

rajveermalviya force-pushed the pr-ios-notif-extension branch 4 times, most recently from dc78826 to 7b54648 Compare February 25, 2026 17:31

rajveermalviya marked this pull request as ready for review February 25, 2026 17:37

rajveermalviya added the maintainer review PR ready for review by Zulip maintainers label Feb 25, 2026

rajveermalviya assigned chrisbobbe Feb 25, 2026

rajveermalviya requested a review from chrisbobbe February 25, 2026 17:38

chrisbobbe reviewed Feb 27, 2026

View reviewed changes

chrisbobbe reviewed Feb 28, 2026

View reviewed changes

rajveermalviya force-pushed the pr-ios-notif-extension branch 2 times, most recently from 09ffdb5 to 3fbbe3b Compare March 3, 2026 15:40

gnprice mentioned this pull request Mar 4, 2026

[iOS] Share to Zulip from other apps #54

Open

gnprice reviewed Mar 4, 2026

View reviewed changes

rajveermalviya force-pushed the pr-ios-notif-extension branch 3 times, most recently from 948d69c to 8e328fb Compare March 5, 2026 15:26

rajveermalviya requested a review from chrisbobbe March 5, 2026 15:51

chrisbobbe mentioned this pull request Mar 5, 2026

store ios: Exclude the database file from iOS backup #2195

Merged

rajveermalviya force-pushed the pr-ios-notif-extension branch from 8e328fb to 3bb22d2 Compare March 10, 2026 10:24

gnprice reviewed Mar 12, 2026

View reviewed changes

gnprice reviewed Mar 13, 2026

View reviewed changes

rajveermalviya added 4 commits March 16, 2026 17:45

ios [nfc]: Extract setting DEVELOPMENT_TEAM to Zulip.xcconfig

1deb5b3

Similar to previous commit, this moves DEVELOPMENT_TEAM config to Zulip.xcconfig, instead of it being specified for different Xcode config sections.

ios [nfc]: In Xcode, run swift-format

d24a6a7

In the Xcode menu bar, Editor -> Structure -> Format file with 'swift-format'.

rajveermalviya force-pushed the pr-ios-notif-extension branch 2 times, most recently from 9e4f78d to 020b68f Compare March 17, 2026 13:36

rajveermalviya force-pushed the pr-ios-notif-extension branch from 020b68f to b186d17 Compare March 17, 2026 14:27

rajveermalviya requested a review from gnprice March 17, 2026 14:28

rajveermalviya force-pushed the pr-ios-notif-extension branch from b186d17 to 314283a Compare March 17, 2026 14:32

gnprice reviewed Mar 17, 2026

View reviewed changes

rajveermalviya mentioned this pull request Mar 17, 2026

notif ios: Decrypt E2EE notifications #2230

Open

rajveermalviya force-pushed the pr-ios-notif-extension branch from 314283a to 437ba9e Compare March 19, 2026 13:55

rajveermalviya added 4 commits March 23, 2026 20:39

ios: Implement ability to intercept APNs push notifications from Dart

9265eaf

Fixes zulip#1265. This uses Pigeons's handy `@FlutterApi` API to define an interface method that allows passing arguments from Swift to Dart and also get a return value back from Dart to Swift.

ios: Add both Runner and NotificationService target to the same app g…

f034f9b

…roup This is required to share any files like database between both app (Runner) and the service extension targets.

store ios: Migrate database file to iOS App Group container path

a857dcd

This will allow the Dart code executing in the notification service extension to access the same database file as the main app target.

rajveermalviya force-pushed the pr-ios-notif-extension branch from 437ba9e to a857dcd Compare March 23, 2026 15:09

gnprice reviewed Mar 27, 2026

View reviewed changes

gnprice reviewed Mar 30, 2026

View reviewed changes

gnprice mentioned this pull request Apr 3, 2026

docs: Port notif and dev-server instructions from legacy app #2265

Open


		IosNotifFlutterApi iosNotifFlutterApi() => TestZulipBinding.instance.iosNotifFlutterApi!;

		test('smoke', () async {

		@@ -0,0 +1,239 @@
		// Autogenerated from Pigeon (v26.1.7), do not edit directly.

		// TODO rename the group identifier.
		const iosAppGroupIdentifier = 'group.zulip.test';

		// TODO change group name
		ZULIP_APP_GROUP_IDENTIFIER=group.zulip.test

		final iosNotifFlutterApiImpl = _IosNotifFlutterApiImpl();
		ZulipBinding.instance.setupIosNotifFlutterApi(iosNotifFlutterApiImpl);

	// TODO debug asserts not working
	// TODO(upstream) debug asserts not working

		class IosNotificationService {
		const IosNotificationService._();

	class IosNotificationService {
	const IosNotificationService._();
	abstract class IosNotificationService {

		final body = alertData['body'] as String?;
		return _ApnsPayload._(title: title, body: body);

-    final parsed = _ApnsPayload.parseApnsPayload(content.payload);
+    final apsData = content.payload['aps'] as Map<Object?, Object?>;
+    final alertData = apsData['alert'] as Map<Object?, Object?>;
+    final title = alertData['title'] as String;
+    final body = alertData['body'] as String?;


		Stream<android_intents_pigeon.AndroidIntentEvent> get androidIntentEvents;

		void setupIosNotifFlutterApi(IosNotifFlutterApi api);

		IosNotificationService.init();
		addTearDown(IosNotificationService.debugReset);

		final pathProviderFoundation = PathProviderFoundation();
		final containerDbDir = await pathProviderFoundation.getContainerPath(

Conversation

rajveermalviya commented Feb 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rajveermalviya commented Feb 25, 2026

Uh oh!

rajveermalviya commented Feb 26, 2026

Uh oh!

chrisbobbe left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rajveermalviya Mar 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

chrisbobbe left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gnprice left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rajveermalviya commented Mar 5, 2026

Uh oh!

chrisbobbe commented Mar 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

chrisbobbe commented Mar 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

chrisbobbe commented Mar 6, 2026

Uh oh!

rajveermalviya commented Feb 18, 2026 •

edited

Loading

rajveermalviya Mar 5, 2026 •

edited

Loading

chrisbobbe left a comment •

edited

Loading

chrisbobbe commented Mar 6, 2026 •

edited

Loading

chrisbobbe commented Mar 6, 2026 •

edited

Loading