Its been 2 days now? What am I missing?

I Check my Index, sing progress on my iPhone 16 with my Mac console and it is stuck at 86% and I made a Check so I checkt the Progress yesterday and Charged it over Night also it was in a Wi-Fi Bad It no progress it’s still at 86%

Apple Mail compose field becomes uneditable after using Apple Intelligence rewriting tools on macOS 27 Developer Beta 1 I am seeing a reproducible issue in Apple Mail on macOS 27 Developer Beta 1 where the compose body becomes locked/uneditable after using Apple Intelligence writing tools. Environment Mac: macOS: macOS 27.0 Developer Beta 1 Build: 26A5353q Device: MacBook Pro with Apple Silicon shouldSwitchToCampoMode: false (isEnhancedSiriAvailable=false) App: Apple Mail Compose window Apple Intelligence Writing Tools Summary When composing an email in Apple Mail, if I write some text and then use Apple Intelligence to rewrite it — for example using Friendly, Professional, or Concise — Mail replaces the original text with the rewritten version. After the rewritten text is inserted, the message body becomes unresponsive. I cannot continue typing, edit the rewritten text, delete text, select text normally, or add new content inside the email body. The Apple Intelligence button also becomes unresponsive after this happens. The only actions that still seem to work are sending the email, discarding the draft, or using some toolbar actions such as emoji insertion. Steps to Reproduce Open Apple Mail on macOS 27 Developer Beta 1. Create a new email. Type any text into the email body. Use Apple Intelligence Writing Tools. Choose a rewrite option such as: Friendly Professional Concise Let Apple Intelligence replace/update the email body text. Try to click back into the message body and continue typing or editing. Expected Result After Apple Intelligence rewrites the email body, the compose field should remain fully editable. The user should be able to: Continue typing after the rewritten text Edit or delete the rewritten text Select and modify text Use Apple Intelligence again on the updated content Continue composing the email normally Actual Result After Apple Intelligence inserts the rewritten text: The email body becomes uneditable. Typing no longer works inside the message body. Clicking inside the body does not restore normal editing. Existing text cannot be edited or changed. Apple Intelligence controls become unresponsive. The compose window itself does not fully crash, but the body editor appears stuck. Send and discard still appear to work. Reproducibility This appears to be reproducible after using Apple Intelligence rewriting tools inside Apple Mail’s compose window. It was working before, so this appears to be a regression in macOS 27 Developer Beta 1.

Porque não tenho permissão para usar tópicos Apple desenvolvimento em.conta empresarial

Hey guys, can everyone share how long an estimated time range it took to get the new siri AI

When I use Siri, it keeps reporting errors.

Hi everyone, Recently I downloaded the last XCode (Version 27.0 beta) and I'm trying to start to play with CoreAI but it's not possible so far to import the CoreAI framework. I'm using the last version of the iPhone simulator. What am I missing?

I’ve found nothing about the waitlist, like when are there expected openings, how does an opening occur, and do I need to do anything else except join the waitlist? It’s been indexing for the same amount of time that I’ve been waiting for Siri, so is that a factor?

One day after I joined Siri waitlist my Siri was updated but it was downgraded to normal siri without Siri ai or Apple Intellegent but in settings it shows Siri

I'm trying to understand the intended relationship between OpenIntent and the new .system.open App Intent schema introduced in iOS 27. From the documentation: OpenIntent (available since iOS 16) is described as an intent that opens an associated item. iOS 27 introduces the .system.open schema, which also appears to represent opening an entity or piece of app content. My questions are: For an app that supports iOS 27+, is .system.open intended to replace OpenIntent, or do the two serve different purposes? For apps that support both iOS 26 and iOS 27+, is the recommended approach to have two structs that implement the same opening logic, one with @AppIntent(schema: .system.open) and the other implementing the OpenIntent protocol? Thanks! References: open protocol OpenIntent

So a few days ago I got the siri ai but after I got out of the waitlist it still won’t lat me use it I’m on ios 27 and PLEASE FIX I WANT A FULL HANDS FREE IPHONE PLZ!!!!!!

The documented template for @AppEntity(schema: .messages.message) at Integrating your messaging app with Apple Intelligence and on the MessagesEntity.message reference page shows: var reaction: <#ReadReaction#>? with <#ReadReaction#> rendered as a placeholder (the Xcode placeholder syntax). A natural reading is "fill in your own type that you want to use here". I tried several: Tapback? where Tapback is @AppEnum(schema: .messages.customReaction) MessageReaction? (same, renamed) MessageReaction? with manual AppEnum conformance (no schema decoration) AttributedString? AttributedString (non-optional) field omitted entirely Each variant produced one of: error: Property 'reaction' type does not match required AppSchemaEntity property type 'ReadReactionCases:(Schema<Tapback> | AttributedString)' error: Required AppSchemaEntity property 'reaction' must be optional error: Missing required property 'reaction' from AppSchemaEntity 'messages.message' The phrase ReadReactionCases:(Schema<Tapback> | AttributedString) is opaque — ReadReactionCases isn't a public type, Schema<Tapback> isn't constructable from outside, and the documentation doesn't mention @UnionValue in this context. The actual working pattern, which I only found by downloading the UnicornChat sample and reading MessageEntity.swift, is: @UnionValue enum MessageReaction: Sendable { case customReaction(CustomReaction) } @AppEnum(schema: .messages.customReaction) enum CustomReaction: String, AppEnum { case sticker static let caseDisplayRepresentations: [Self: DisplayRepresentation] = [ .sticker: "Sticker" ] } Two suggestions: Update the schema-template comment in the docs to either name MessageReaction explicitly with a @UnionValue annotation, or include a one-line note: "The reaction field is a @UnionValue enum wrapping the customReaction schema enum — see UnicornChat sample." The current placeholder <#ReadReaction#> plus the prose suggesting "you can generate the properties... with the @AppEntity(.messages.message) Swift macro" reads as if the developer just supplies any AppEnum-conformer. Improve the diagnostic. Property type does not match required AppSchemaEntity property type 'ReadReactionCases:(Schema<Tapback> | AttributedString)' is unhelpful because ReadReactionCases doesn't appear in any reachable type. Either rename to something developer-facing, or include a fix-it that suggests @UnionValue. iOS 27.0 beta, Xcode 27 beta, macOS Tahoe 26.4.

I haven’t yet installed the iOS 27 beta on my iPhone so I can’t yet try out some of the new feature in Image Playground. But what I’d like to be able to do is: let our users upload a photo of an object and then have Image Playground create a more polished version of the same photo. in pre-iOS 27 Image Playground, I can do this and get an illustration back. Can I get a photo back with the new changes? Is this something we can do yet with Image Playground?

I am still on the waitlist since Day 1… Such a poor preparedness and leadership by Apple… That’s it… My primary Sim is going back to Samsung…

still been on the waiting list ever since, don’t know what’s going on with this waitlist. I understand it’s not list list, but it’s taking forever!

Our app already has a huge set of App Intents and Entities. Conceptually, our entities and intents matches well to the existing schemas (like the Notes schema). But because we have existing intents, we ran into two problems: Our existing intents/entities used different property names in the past and some properties are slightly different then the schema. Our existing intents are already used on older Versions of macOS / iOS. But the schema domain is only available on OS27 and later. What can we do to adopt the schema? Should we just duplicate all Intents / Entities and mark them as isAssistantOnly and limit their availability to OS27 and later?

Going on a week now and still on the waitlist 👎

Hi all :) I tried to raise this in the group lab and was pointed here. I’m seeing a flat per-app memory ceiling of about 6 GB on iPhone, even on devices with more physical RAM and with com.apple.developer.kernel.increased-memory-limit. Measured with os_proc_available_memory() plus task_vm_info.phys_footprint, the total process budget stays around 6144 MB on both: iPhone 16 Pro Max, 8 GB RAM iPhone 17 Pro Max, 12 GB RAM This came up while running Gemma 4 multimodal support in mlx-swift-lm (PR #343). The model loads at about 4.4 GB resident, leaving roughly 1.7 GB for inference/prefill. Reducing a GPU buffer cache from 512 MB to 64 MB recovered enough headroom to avoid jetsam and allowed a full image + video + audio multimodal test to complete, so the measurement seems to reflect a real per-process limit rather than free system memory. I re-measured the ceiling on the 12 GB phone with these capabilities: increased-memory-limit only: ~6144 MB increased-memory-limit + extended-virtual-addressing: ~6144 MB, no change increased-memory-limit + increased-debugging-memory-limit: ~6656 MB I have also observed that 12 GB iPad devices expose more memory to an app than 12 GB iPhone devices but I didn't measure specifically and no longer have the device to hand. Is the ~6 GB per-process tier on Pro iPhones expected, even with increased-memory-limit? Is there any supported way for a shipping app to access more of the available RAM on 12 GB iPhone models? FB23183521

I’ve been waiting for like a week, but still nothing show up. Can you guys do things faster?

I am concerned how easy they make it to generate photos of real people. And because it is so easy, people will likely just try it on people without their consent. At the WWDC26 keynote, they demonstrated how you can use any photo of a person to create a new photorealistic image based on modifications described using natural language. I would even describe this as creepy. Anyone who can find a photo of me online, can create a photo of me doing whatever they want! And of course, I have no control over who they share that with. I believe Apple could do better than the other AI companies. At minimum, they could display some warnings about the ethical considerations when using this feature.