Team-scoped keys introduce the ability to restrict your token authentication keys to either development or production environments. Topic-specific keys in addition to environment isolation allow you to associate each key with a specific Bundle ID streamlining key management. For detailed instructions on accessing these features, read our updated documentation on establishing a token-based connection to APNs.

Hello developers! Thank you for your dedication to creating apps with great performance. We’re excited to kick off another year of partnering with you on improving power and performance in your apps. At WWDC26, check out the following new things in the latest platform SDKs and Xcode 27 beta for performance. You can also join us online for a Power and Performance Group Lab on Tuesday, June 9 at 11 AM Pacific. Meet State Reporting and the new MetricKit State reporting: The new StateReporting framework lets your application express its state to downstream tools like Instruments and MetricKit. Make your telemetry and traces much more useful by adopting this simple API. MetricKit: In the 27 releases, the Swift-first MetricManager API replaces the MXMetricManager API. Combined with State Reporting, the new MetricKit provides more granular metrics to isolate performance problems faster. It also provides a more expressive API that is great to use in Swift, with improved Swift concurrency and Codable support. With this year’s releases, the MXMetricManager API is considered legacy. ▶️ To learn more, watch Meet the new MetricKit. Discover new features in Xcode organizer Metric goals: Xcode organizer now provides a goal metric for Battery Usage, Disk Writes, Hang Rate, Hitches, Memory, and Storage metrics, allowing you to prioritize performance engineering across more areas. Generate recommendations: Quickly resolve the highest impact performance issues in your app by using Generate Recommendations for Crash, Energy, Disk Write, Hang and Launch diagnostics. Insights overview: The new insights overview in Xcode organizer summarizes high-impact performance regressions for metrics and diagnostic reports, helping you plan and prioritize performance engineering work. Storage metrics: Storage metrics are now available in Xcode organizer, allowing you to monitor your app's Documents & Data and App Size across releases and catch regressions in cache usage and bundle size. Hitches metric: The new Hitches metric replaces the Scrolling metric in the organizer and now displays hitches for all animations in your app, giving you a comprehensive view of animation performance. ▶️ To learn more about other advancements in Xcode, watch What’s new in Xcode 27. Improve app responsiveness with Instruments Foundation Models: The Foundation Models instrument is redesigned with a tree view that lets you drill into individual requests, inspecting tool call arguments and results, inference prompts and responses, and token statistics. Use it to understand caching behavior, measure latency, and optimize throughput. System Trace: System calls, VM faults, and thread states are now unified into a single plot, with a new blending algorithm that stays readable even at high density. Once you spot something worth investigating, left/right key navigation lets you follow a thread's activity step by step, and the inspector provides quick actions like pinning the thread that made another thread runnable. System Trace now also draws thread priority and QoS over time, making it easier to identify priority inversions and unexpected QoS degradations that affect responsiveness. Swift Concurrency: New Main Actor and Global Concurrent Executor tracks let you visualize running tasks and executor queue depth over time, making it easier to spot task scheduling delays and actor contention. Tasks are now grouped into collections for faster navigation. Swift Tasks, Actors, and Executors instruments can now surface Call Trees, Flame Graphs, and Top Functions scoped to each entity — so you can pinpoint exactly where concurrency overhead lives. Top Functions: Helper functions and runtime internals can be expensive but hard to spot in a standard call tree. The new aggregation mode in Top Functions surfaces any function's total execution time across the entire call stack, making it easy to identify and prioritize hidden hotspots. Run Comparison: Compare call tree data across builds to identify regressions and performance wins. Results can be explored as an outline, flame graph, or top functions — choose whichever view best fits your workflow. ▶️ To learn more about profiling your app with Instruments, watch “Profile, fix, and verify: Improve app responsiveness with Instruments” ▶️ To learn about Foundation Models optimization, watch “Debug and profile agentic app experiences with Instruments”. If you have any questions about using State Reporting or the new MetricKit, create a post on the forums. For help creating a post, see Tips on writing a forum posts.

I have two lines through Verizon wireless, my main line for the account was acting like a dead eSIM every time it is on it kills my data completely even on the second phone line unable to send a receive phone calls, send a receive text messages, retrieve voicemails, or use data in any capacity from that line. I have completely deleted and reinstalled and reactivated eSIM for that line a handful of times in the last week/week and a half & it is the main account line being rendered completely unusabl.

Summary On an M2 Max (macOS 26.5.1, 25F80), WindowServer intermittently stops checking in with the userspace watchdog ("hung 40/80 seconds since last successful checkin") and the machine resets. The part I'm asking about: since ~2026-06-17 the wedge no longer ends in a normal panic-reboot — it escalates to recoveryOS and forces a full Mac reactivation (local password + iCloud). Four times in 55 hours. The most recent was captured live and fired on a machine that was idle, memory-clean (1.2 GB free, flat swap, no Jetsam), with the underlying IOKit power-assertion count plateaued — so this is not resource exhaustion at the moment of the wedge. It reproduces under a heavy third-party workload (an Electron app's per-session process fan-out, tracked separately by the vendor). I'm not asking Apple to fix that app — I'm asking about the OS behaviors that turn "an app uses a lot over many hours" into "the owner is locked out pending iCloud reactivation." Apple-side vs app-side (so this isn't dismissed as a third-party issue) Apple's — and these should hold regardless of any app, because no userspace workload should be able to cause them: A userspace WindowServer watchdog timeout escalating to a firmware/recoveryOS reset that invalidates the boot policy and demands iCloud reactivation. On disk, the four 06-18→06-20 events have the WindowServer watchdog .spin/.ips but no panic-full and no ResetCounter — they did not take the normal panic-reboot path. The watchdog resetting the whole machine instead of restarting the wedged compositor ("WindowServer has not exited since first loaded"). WindowServer/SkyLight degrading cumulatively under sustained use so the wedge fires even when the machine is currently idle and memory-clean (below). IOKit never reclaiming RootDomainUserClient (IOPMrootDomain) registrations — they accumulate unbounded and clear only on reboot, and the dominant holders are Apple's own daemons (apsd, WebThumbnailExtension), not the app. App-side (separate tracker): unbounded per-session MCP process fan-out + an Electron footprint + a held NoIdleSleep assertion forcing sustained display-on operation. That controls how fast you reach the degraded state; the OS controls whether reaching it is a graceful degrade or an owner-lockout. Event 4 shows the OS failure with no resource exhaustion present at all. System MacBook Pro 14" (Mac14,5), M2 Max (T6020), 38-core GPU, 32 GB — a high-end, fully capable machine I had essentially never needed to reboot before this; it now forces a reactivation roughly once per day of use. macOS 26.5.1 (25F80), kernel xnu-12377.121.6~2 (Darwin 25.5.0). FileVault on, no third-party kexts, 161 GB free disk. Same kernel build as 25F71 — the update didn't change it. Signature userspace watchdog timeout: no successful checkins from WindowServer (0 induced crashes) in 120 seconds WindowServer has not exited since first loaded service: logd / opendirectoryd / configd — last checkin: 0 seconds ago service: WindowServer — last checkin: 120 seconds ago Panicked task ... watchdogd; KEXT backtrace: AppleARMWatchdogTimer -> AppleARMPlatform Compressor Info: NN% (OK) ... 0 swapfiles <-- memory-clean Only WindowServer is stuck; logd/opendirectoryd/configd check in normally. Pre-reset spindumps show ws_main_thread off-CPU ~59 s, wedged in SkyLight → QuartzCore CA::Transaction::commit / CALayer render-commit. Two spindumps per event (the 40 s/80 s checkpoints before the 120 s reset). Timeline & the escalation point (verifiable on disk by panic-full/ResetCounter presence) Normal panic-reboots (panic-full + ResetCounter written): 06-15 22:24 (~6.2 h uptime), 06-16 11:39 (~13.2 h), plus 06-14 / 06-15 16:07 / 06-16 20:08. Latest panic-full on disk = 06-16 20:08. Escalated to recoveryOS reactivation (NO panic-full, NO ResetCounter): # When WindowServer uptime at wedge state R1 06-18 01:23 ~27.6 h (99,278 s) R2 06-18 19:53 ~18.4 h (66,201 s) + Jetsam pressure R3 06-19 15:30 ~19.2 h (68,991 s) R4 06-20 08:19 ~16.7 h (60,180 s) idle, 1.2 GB free, leak plateaued 583 Uptime = WindowServer-process uptime from the .ips "M checkins since K seconds ago" field (the coarse uptime JSON field — 99000/66000/69000/60000 — corroborates). Time-to-wedge is not a fixed interval — it ranges ~6–28 h and scales inversely with GPU/compositor load; the invariant is sustained use, not a clock value. After 06-16 there are zero panic-full and zero ResetCounter on disk — the fingerprint of the recoveryOS escalation. Decisive evidence — R4, captured live A monitor sampling every 2.5 min when WindowServer wedged (08:19, 16.7 h): 08:14 iopm=581 free=1833MB swap=3732MB load=2.88 08:19 iopm=583 free=1192MB swap=3724MB load=3.03 <-- watchdog spindump written Idle (load ~3), 1.2 GB free, flat swap, no Jetsam, the IOKit power-assertion count plateaued at 583. Nothing to exhaust — it still wedged and escalated to reactivation. The trigger is cumulative WindowServer/SkyLight state, not the resource level. The leak (an aggravator) RootDomainUserClient/IOPMrootDomain clients climb without bound (baseline ~120 → 583–923 here). Dominant holders are Apple daemons (live ioreg walk 2 min pre-panic: apsd 228/596, then Safari/WindowServer/powerd/loginwindow). Killing the top creating process does not reclaim them (ioclasscount 526→526) — kernel-orphaned, reboot-only. Per R4 the leak is an aggravator, not the threshold (583 wedged; 923 had not earlier). Ruled out Hardware (survived 25F71→25F80, same kernel; peripheral + driver removal); memory exhaustion (R4 and others memory-clean); a fixed clock (load-dependent, 6–28 h); an iopm threshold (R4 plateaued at 583). Questions for Apple engineering Why does a userspace WindowServer watchdog timeout escalate to recoveryOS + forced reactivation (boot-policy re-verification) instead of a normal panic-reboot? What invalidates LocalPolicy / triggers Activation-Lock re-verification on this path? What in WindowServer/SkyLight degrades cumulatively over sustained use so a render-commit can't complete within the watchdog window even on an idle, memory-clean machine? Can the watchdog restart the wedged WindowServer ("has not exited since first loaded") instead of resetting the whole machine into a reactivation lockout? Can IOKit lifecycle-bound RootDomainUserClient (IOPMrootDomain) registrations so they don't accumulate unreclaimable? Dominant creators are Apple daemons (apsd, WebThumbnailExtension). Apple Feedback FB22947849 has the per-event spindumps, .ips, the live monitor log, and a sysdiagnose. I'd most appreciate a pointer on #1 — the reactivation escalation is what turns a recoverable crash into a repeated owner-lockout.

When a user uses the "Add Name" feature on an unknown number in their Call Logs, the name appears under "Other Known Contacts" in the native iOS Contacts app. The Problem: CNContactStore completely ignores these contacts during a standard fetch/enumeration. When user gives limited permission they can search for that contact and select it, but it won't be visible in my App as it's not technically a contact. Is CNContactStore intentionally blocked from reading "Other Known Contacts" for privacy reasons or are there any future plans to expose API so that third party apps can access it?

A brand-new MacBook Pro (M5 Pro, 24GB RAM) is experiencing frequent, severe kernel panics. The system freezes completely for a few seconds before executing an automatic reboot or shutdown. This behavior occurs roughly 10+ times per day, significantly disrupting production work. The issue initially triggered immediately after migrating data from a base M4 MacBook Pro via Migration Assistant. Steps Taken & Troubleshooting Hardware Diagnostics: Ran Apple Diagnostics locally; all hardware checks passed with no errors detected. OS Updates: Installed the minor macOS patch intended to resolve M5 automatic reboot bugs. The issue persisted. System Erase: Performed a complete factory reset ("Erase All Content and Settings") and a clean OS reinstallation as advised by Apple Support. Beta Testing: Upgraded to the macOS Tahoe Beta following guidance from a DST Engineer who indicated the issue was addressed in this build. The frequent crashes continue to occur on the beta track. Case / Feedback Reference Feedback ID: FB23273513 (Captured after the system format)

I've built an open-source DriverKit + NetworkingDriverKit (IOUserNetworkEthernet/Skywalk) driver for a USB 5GbE adapter (AQTION AQC111U chipset). As far as I can tell this is the first public one for real third-party hardware: github.com/jquirke/AQC111Driver It's a fully functional driver at this point: RX/TX hardware checksum offload, jumbo frame/MTU control up to 16KB, runtime-controllable diagnostics via a custom IOUserClient, and most recently working 802.1Q VLAN support via macOS's vlan(4) software path. While attempting to implement hardware offload VLAN support, I ran into what looks like a gap between documentation and the public SDK, and I'd appreciate expert opinion either way before filing Feedback. The issue: IOUserNetworkPacket::getVlanTag()/setVlanTag() (DriverKit 24.0+) have a doc comment stating: "Get the Vlan Tag from the packet, where the driver has enabled the kFeatureHardwareVlan capability; for the case that feature is not enabled, this method will return false." kFeatureHardwareVlan does not appear anywhere in the public NetworkingDriverKit.framework/Headers/ tree confirmed via exhaustive grep, including the full hwAssist/feature-flag enum in IOUserNetworkTypes.h. I tested every plausible related mechanism exhaustively, with a real device reattach for each combination, to rule out attach-time-only behaviour: +------------------------+--------------------------+--------------+-----------+ | HWAssist bit declared? | SetSoftwareVlanSupport()| getVlanTag() | vlan0 MTU | +------------------------+--------------------------+--------------+-----------+ | Yes | true | always false | 1500 | | Yes | false | always false | 1500 | | No | not called | always false | 1496 | | No | false | always false | 1496 | +------------------------+--------------------------+--------------+-----------+ none of these combinations gates real 802.1q tag-delivery/demux behavior at all; it seems Vlan support is completely implemented in software on the MacOS side and I have to explicitly program my hardware registers to disable VLAN tagging. Question: is hardware VLAN tag insert/strip (via getVlanTag()/setVlanTag()) currently reachable from a third-party DriverKit USB Ethernet driver at all? If kFeatureHardwareVlan is real but intentionally withheld from public headers, is there a documented path (entitlement, different NDK version, etc.) to enable it or is this confirmed unreachable without Apple's direct involvement (Feedback/DTS)? Can share full test logs/methodology if useful.

NSJSONSerialization silently drops U+FEFF from JSON string content — keys merge, characters vanish TL;DR: NSJSONSerialization deletes U+FEFF (ZERO WIDTH NO-BREAK SPACE / BOM) from anywhere inside parsed JSON strings — not just a leading document BOM, and even when written as the \uFEFF escape (it's removed after unescaping). Distinct strings/keys silently collapse onto their U+FEFF-less twins. If you're seeing JSON keys mysteriously merge or a character disappear from a parsed value, this is probably why. It is not your code. Workaround and exhaustive scope below. The workaround Two options, depending on how attached you are to Foundation: A. Stay on NSJSONSerialization — swap U+FEFF for a private-use sentinel before parsing, restore after. You must handle both the raw bytes and the \uFEFF escape (the escape bites too, since deletion happens post-unescape): // 1. Pick a private-use scalar you've verified is absent from the source text. // 2. Replace every in-content U+FEFF (raw char AND \uFEFF escape) with it. // 3. Parse. NSJSONSerialization preserves the sentinel. // 4. Recursively restore the sentinel -> U+FEFF in the parsed tree. static id RestoreSentinel(id o, NSString *s, NSString *bom) { if ([o isKindOfClass:NSString.class]) return [o rangeOfString:s].location == NSNotFound ? o : [o stringByReplacingOccurrencesOfString:s withString:bom]; if ([o isKindOfClass:NSArray.class]) { NSMutableArray *a = [NSMutableArray arrayWithCapacity:[o count]]; for (id e in o) [a addObject:RestoreSentinel(e, s, bom)]; return a; } if ([o isKindOfClass:NSDictionary.class]) { NSMutableDictionary *d = [NSMutableDictionary dictionary]; [o enumerateKeysAndObjectsUsingBlock:^(id k, id v, BOOL *stop) { d[RestoreSentinel(k, s, bom)] = RestoreSentinel(v, s, bom); }]; return d; } return o; } Swap the escape form with a backslash-parity-aware regex so \uFEFF (escaped backslash + literal "uFEFF") is left intact: (?<!\\)((?:\\\\)*)\\u[Ff][Ee][Ff][Ff] -> $1<sentinel> B. Don't use Foundation for this file — a spec-compliant C parser like ++yyjson++ preserves U+FEFF and is faster on large files. (This is the route swift-transformers took for tokenizer.json.) Minimal repro // Object keys collapse: NSData *d1 = [@"{\"\\uFEFF#\":1,\"#\":2}" dataUsingEncoding:NSUTF8StringEncoding]; id o1 = [NSJSONSerialization JSONObjectWithData:d1 options:0 error:nil]; // EXPECTED: 2 keys ("\uFEFF#" and "#"); ACTUAL: 1 key ("#") — \uFEFF stripped, keys merged // String content lost: NSData *d2 = [@"[\"\\uFEFF\"]" dataUsingEncoding:NSUTF8StringEncoding]; id o2 = [NSJSONSerialization JSONObjectWithData:d2 options:0 error:nil]; // EXPECTED: ["\uFEFF"] (one code point); ACTUAL: [""] (empty string) Same outcome whether U+FEFF arrives as raw EF BB BF bytes or the \uFEFF escape. Why this is a bug, not a quirk Per RFC 8259 §7, a JSON string is a sequence of Unicode code points; U+FEFF is ordinary content and doesn't require escaping. Tolerating a leading document BOM is fine — deleting U+FEFF from string content is not. U+FEFF leads a double life (BOM signal vs. ZERO WIDTH NO-BREAK SPACE character); Foundation treats every occurrence as a stray BOM to scrub. Scope — exhaustive, not anecdotal I swept all 1,112,064 valid Unicode scalars (U+0000–U+10FFFF minus surrogates) through a parse round-trip, in both the \uFEFF-escape and raw-UTF-8 forms: U+FEFF is the only scalar altered. Every other scalar round-trips byte-identically — including the other zero-widths (U+200B, U+2060, U+00A0), which all survive. No Unicode normalization occurs (NFD stays decomposed, combining sequences and compatibility characters are preserved). So this is a deliberate BOM-stripping heuristic applied too broadly to string content — narrow and fixable, not general mangling. Why it's nasty in practice U+FEFF is zero-width, so the corruption is invisible — no trace in a diff or editor. Real-world hit: ML tokenizer vocabularies (e.g. Google's Gemma) legitimately contain U+FEFF-bearing tokens; loading tokenizer.json via NSJSONSerialization collapses those keys and assigns wrong token IDs, with zero visible symptom until output is subtly wrong. Filed as FB23271905 — please dupe if this has bitten you. More duplicates is what gets it triaged.

Hi, I really need suggestion on how to get into Apple's Development Payment Department team's attention. I'm using Singaporean contact and address, but currently has to be in Indonesia for quite a while. I registered and put in my creditcard detail, and later got the email from Apple that I need to contact my card provider, which is a frustrating and expensive experience since I have to call roaming, and the line keeps dropping after few mins call. I tried emailing Apple Dev/Payment requesting different payment method, but so far have not received any feedback, and I need to import my flutter into ios apps for closed testing and presenting it early next week. Please, if anyone knows how to I should be able to get them to respond, there will be great. Thank you.

Device: iPhone 17 Pro iOS Version: iOS 27 beta Problem Description I am experiencing the following issues on iOS 27 Beta: Bluetooth randomly turns off and on automatically • Bluetooth occasionally turns off by itself for a few seconds and then turns back on. • The issue is especially severe when connected to AirPods Pro 2 (latest beta firmware), but it also occurs even without AirPods connected. • It usually only starts happening frequently after the iPhone has been powered on for a long time. Restarting the device temporarily resolves it. 2. Network Connection Issues • Network frequently experiences lag and slow speeds. • The problem becomes particularly noticeable when cellular data is throttled to 1 Mbps. • Even when multiple strong Wi-Fi signals are available, the device often ignores them and continues using or automatically switches back to cellular data (relatively frequent intermittent issue). 3. Feedback Assistant completely broken • Trying to submit feedback through the Feedback Assistant app delay fails with the following error: 开始反馈时出错 请稍后再试。

I could not find iCloud invading capabilities, it Shows nothing found, is there a problem in account or what

We’re planning a migration from App Store Server Notifications V1 to V2 and are reviewing our rollback strategy before enabling V2 in production. While researching, we found TN3180: TN3180: Reverting to App Store Server Notifications V1 | Apple Developer Documentation The technote appears to describe reverting App Store Server Notifications from V2 back to V1 using the Modify an App endpoint. Before proceeding, we’d like to clarify a few points: Is V2 → V1 rollback via the Modify App endpoint fully supported for production applications? If an application is reverted from V2 back to V1, can it later be migrated back to V2 again? During a rollback, should developers expect any overlap period where both V1 and V2 notifications may be delivered due to retries or notifications already in flight? Our goal is to understand whether the V2 → V1 capability should be treated as a fully supported operational rollback mechanism or as an emergency recovery path intended only for exceptional situations. Thank you for any clarification.

I generated an Apple Maps API key and Server API test token via Maps services, and checked it has a valid header and payload with jwt. Ive also generated a valid token with my AuthKey_.p8 file via PyJWT, however, I continue to get 401 error returned from my local server when trying to test hitting https://maps-api.apple.com/v1/api/searchAutocomplete?....

Hey, I've been banging my head against this for a few days now and genuinely can't figure out if it's something on my end or an Apple backend issue. My app has WeatherKit integrated and it works fine in the simulator, but on my physical device I consistently get this in the console: Failed to generate jwt token for: com.apple.weatherkit.authservice Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" Things I've already tried and ruled out: WeatherKit capability is enabled in the App ID on developer.apple.com ✓ com.apple.developer.weatherkit = true is in the entitlements file ✓ Removed and re-added the capability in Xcode Signing & Capabilities ✓ Clean Build Folder, fresh install on device ✓ The location coordinates are valid (hardcoded lat/lon in Bavaria) ✓ The weird part is that it's not a location issue — Error Code 2 from WDSJWTAuthenticatorServiceListener suggests the JWT generation itself is failing before any location lookup even happens. I've had this App ID since early this year, WeatherKit was working at some point, and I'm not sure what changed. My fallback to Open-Meteo works fine so the app isn't broken, but I'd like to actually use the API I'm paying for. I also opened a support ticket but got redirected to the forums, so here I am. Anyone else seen this recently or know if there's something on the provisioning side I'm missing?

https://developer.apple.com/documentation/declaredagerange/ https://developer.apple.com/documentation/declaredagerange/agerangeservice/requiredregulatoryfeatures For these API, (1) How is Apple determining the user is in Texas? IP or Address on the account? (2) How do we know if an API is active. Testing today (6/18) we are seeing both false in a region/state where the law is now in effect. (3) How will we know when Apple adds more regions to the API enablement? Is there a communication channel for this?

I develop a tool on macOS which is composed of an UI app to manage the main app settings, and an Agent that runs in background doing some tasks ? (Running the agent is optional, can be launched from the UI app, and can be launched by macOS at startup with SMAppService. ) Agent has the LSUIElement flag set, and only shows a Menu Extra (or whatever it now named), and sometimes some notifications. The whole App package is bundled this way MainAppUI.app/Contents/Library/LoginItems/AppAgent.app (for SMAppService to work) This has been working correctly for years Now on macOS 27 beta, once I quit the UI App, having launched the Agent, the Dock reports the UI App is still running in background (with the grey dot) . But only the Agent is running, not the UI app process. Moreover, System Settings->Background apps reports both the UI app AND the Agent as both requesting to run in background. I would have expected only the Agent being listed in System Settings, and nothing appearing in the Dock. Is this a bug in the OS beta , showing the top-level container bundle as the app running in background instead of the executable direct container ? Or maybe it's on me and I should bundle my app differently ? (I cannot "reverse" the bundle and put the Agent as the main app, with UI "inside", as double clicking the main app should launch the UI App , not the Agent. ) BTW, filed FB23203848 for the same subject. thanks for any direction

Im trying to implement add to Apple Pay feature in my app. I have an issuer bank's credit card as an existing feature. Now question is, say its added successfully already, I relaunch my app, how to tell if already added to Apple Pay? I have made some reads, and asked AIs, but I can't seem to get a clear answer. Passkit's primaryAccountIdentifier - if use this, how will our backend store this? I mean, I don't think its ideal approach for mobile app to be responsible for calling backend api. deviceAccountNumberSuffix - what if my app have other cards that can be added to Apple Pay and has same suffix. Then seems broken flow.

What is wrong with you people man I've been bashing my head for two days it just won't work, I'm trying build a React Native app but unable to connect my phone to my macbook local server I have stopped development it's taking out all the enthusiasm out of it. I'm on the edge, everything work when it's xcode building, installing the app but the moment I switch to React Native(Antigravity) it just wont connect, sometime it connects randomly and then is suddenly stops, should I drop everything and just use apple for everything? Why wont you just ban app development outside xcode completely?

Hi everyone! I'm writing a watch app using backgroud refresh. But the backround task was not triggered either on simulator or real watch device. main code

Not sure if this is an intented change in terms of UI on 27 beta 1, but I think the previous implementation of configuring array of App Entity is better with a list and options and reorder and remove items. My widget configuration code: struct BusWidgetConfiguration: WidgetConfigurationIntent { static var title: LocalizedStringResource { "Bus Stop Configuration" } static var description: IntentDescription { "Configure youe top 3 most commonly used bus stop to open in app." } @Parameter(title: "Bus Stop", default: [], size: IntentCollectionSize(min: 0, max: 3)) var busStops: [BusStopEntity] @Parameter(title: "Open in Maps", default: false) var openInMaps: Bool } iOS 27 Beta 1: iOS 26.5:

I am using ActivityKit push-to-start Live Activities on iOS 17.2 and later. In a small number of user reports, the app is never able to obtain Activity<LiveActivityAttributes>.pushToStartToken. The flow is: Task { if let token = Activity<LiveActivityAttributes>.pushToStartToken { // cache and upload token } else { // logged: current push-to-start token is nil } for await token in Activity<LiveActivityAttributes>.pushToStartTokenUpdates { // cache and upload token } } This task is started when the app launches. For the affected users: Activity<LiveActivityAttributes>.pushToStartToken returns nil at app launch. Activity<LiveActivityAttributes>.pushToStartTokenUpdates never emits any value. After waiting for a while, reading Activity<LiveActivityAttributes>.pushToStartToken again still returns nil. When an existing Live Activity ends or expires, the app retries and reads Activity<LiveActivityAttributes>.pushToStartToken again, but it is still nil. Example log from the retry after the Live Activity ended: [Live Activity][retryDisplayCreationAfterLiveActivityEnded] Failed to read PushToStart token. local entity is nil: true In this case, the local entity is empty because no push-to-start token was ever received from ActivityKit. This is not about the per-activity activity.pushToken; the issue is specifically with the app-level Activity<Attributes>.pushToStartToken. Because the push-to-start token remains empty, our server cannot send a push-to-start request for that user. I have seen a previous forum response mentioning a timing issue before iOS 26, but this affected case is on iOS 26.5, so I am not sure whether this is the same issue or a different condition. Questions: Under what conditions can Activity<Attributes>.pushToStartToken remain nil indefinitely? Is pushToStartTokenUpdates expected to emit the current token after app launch, or only future token changes? If the initial pushToStartToken read returns nil, what is the recommended retry strategy on iOS 26.5? Does Live Activities authorization, notification permission, APNs registration state, app install source, or device state affect generation of the push-to-start token? What logs or sysdiagnose information would be useful to confirm whether this is an ActivityKit issue? Environment: iOS version: 26.5 Device model: iPhone 17 App install source: TestFlight Xcode version: 26.3 ActivityKit usage: push-to-start Live Activity Any guidance on whether this is expected behavior, a known issue, or something we should file through Feedback Assistant would be appreciated.

I would like to know whether it is possible to collect Wi-Fi signal strength on iOS 18 from an iPhone app. I need to measure Wi-Fi signal strength for an internal app. The app is not intended for App Store distribution. I enabled the Access WiFi Information capability and tested NEHotspotNetwork.fetchCurrent(). SSID and BSSID are returned correctly, but signalStrength always returns 0.0. Is there any official or supported way to get the current Wi-Fi RSSI/signal strength on iOS 18? For example, is this possible through NEHotspotNetwork, NEHotspotHelper, or any other iOS API?