Post

Replies

Boosts

Views

Activity

`ContextMenu` and `Menu` Item Layout: Icon/Title Order Discrepancy Between System and Custom Apps (iOS 26)
I've observed a difference in the layout of menu items within ContextMenu and Menu when comparing system applications to my own SwiftUI app, specifically concerning the order of icons and titles. On iOS 26, system apps (as shown in the image in the "System App" column) appear to display the item's icon before its title for certain menu items. However, in my SwiftUI app, when I use a Label (e.g. Label("Paste", systemImage: "doc.on.clipboard")) or an HStack containing an Image and Text, the icon consistently appears after the title within both ContextMenu and Menu items. I'm aiming to achieve the "icon first, then title" layout as seen in system apps. My attempts to arrange this order using HStack directly within the Button's label closure: Menu { Button { /* ... */ } label: { HStack { Image(systemName: "doc.on.clipboard") Text(String(localized: "Paste")) } } // ... } label: { Text("タップミー") } seem to be overridden or restricted by the OS, which forces the icon to the leading position (as shown in the image in the "Custom App" column). System App Custom App Is there a specific SwiftUI modifier, or any other setting I might have overlooked that allows developers to control the icon/title order within ContextMenu or Menu items to match the system's behavior? Or is this a system-controlled layout that app developers currently cannot customize, and we need to wait for potential changes from Apple to expose this capability for in-app menus? Thanks in advance!
1
0
146
Jul ’25
`Hideable` MDM attribute not preventing app hiding
I have come across this Hideable attribute for managed apps, introduced in iOS 18.1, and I've encountered some behavior that seems to contradict the official documentation. According to Apple's documentation for app.managed.yaml, setting the Hideable key to false under the Attributes section should prevent a user from hiding the app. The documentation explicitly states: If false, the system prevents the user from hiding the app. It doesn't affect the user's ability to leave it in the App Library, while removing it from the Home Screen. I have configured this in my app.managed.yaml and successfully applied the profile to my test device via our MDM server. However, I am still able to hide the application from both the Home Screen and the App Library. Here are the steps I'm taking to hide the app: Long-press the app icon on Home Screen Select "Require Touch ID" Select "Hide and Require Touch ID" Authenticate using Touch ID Select "Hide App" After these steps, the app is no longer visible on the Home Screen or in the App Library, which is contrary to the behavior described in the documentation for when Hideable is set to false. My question is: Is this a known issue or a potential bug in iOS 18.1? Or, is there an additional configuration profile or a specific device supervision requirement that I might be missing to enforce this restriction correctly? Any clarification would be greatly appreciated! Thank you!
0
0
89
Jul ’25
MDM AppConfig: Configuration Plist Structure Discrepancy (Top-Level 'configuration' Key)
I'm currently implementing a managed app using the new AppConfig specification. I referred to Apple's official documentation: Specifying and decoding a configuration. Based on the example provided in the "Publish your configuration specification" section, I structured my application configuration plist like this: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>configuration</key> <dict> <key>account</key> <dict> <key>username</key> <string>test user</string> <key>password</key> <string>test 123</string> </dict> <key>domain</key> <string>test example.com</string> </dict> </dict> </plist> When I deployed this configuration via my MDM server, the server reported valid for the activation, configuration and asset (which is the plist), but the configuration did not reflect or apply within my app. My app was unable to retrieve these settings. After some troubleshooting, I found that removing the top-level <key>configuration</key> wrapper resolved the issue. The following plist structure successfully pushed the configuration to my app: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>account</key> <dict> <key>username</key> <string>test user</string> <key>password</key> <string>test 123</string> </dict> <key>domain</key> <string>test example.com</string> </dict> </plist> My question is: Is the inclusion of the <key>configuration</key> wrapper (as shown in the Apple documentation example) incorrect for the current AppConfig implementation? Or is this structure intended for a future release (e.g., iOS 26 or beyond) and the documentation implicitly refers to it, causing confusion for current implementation? Any clarification would be greatly appreciated! Thank you!
2
0
521
Jul ’25