John Brayton

  • My glass shower door (which has probably been in place for 29 years) spontaneously shattered earlier today. No one was anywhere near it when this happened.

  • Tonight’s online CocoaHeads meeting will include a presentation on Skip, an Xcode plugin that transpiles native SwiftUI iOS apps into Android apps using Jetpack Compose and Kotlin. New participants and participants from outside the Boston area are always welcome.

  • Election

    I was also a precinct clerk, but we don’t get stickers for that. 🤣

    We had a preliminary election for mayor, city council, and school committee in my city today. This is a big one. Our mayor of 20 years is retiring, and it’s the first city election since deciding to have ward-specific city councilors and school committee members.

    Hilariously we (probably) have 3 more elections between now and the end of March.

    “I Voted” sticker.

  • I filed an FB a few days ago regarding the need for an API that does not exist on macOS. Apple replied with “We believe the reported problem has been fixed. Please verify that the issue does not reproduce on macOS 14 beta 7…” 🤦‍♂️

  • Chime is a polished text editor for the Mac with support for several programming languages and an extension API. Now @mattiem@mastodon.social is generously making the app free and releasing the source code.

  • A bird wandering around an indoor train station.

    Photo of bird inside a train station.

  • A fourth indictment. I am starting to suspect Trump might be guilty of some of the crimes we watched him commit on TV. ⚖️

  • CocoaHeads Boston will meet in person next Tuesday, August 22, at Cambridge Brewing Company. New participants are always welcome. Please RSVP on Meetup if you expect to join us so that we can make an educated guess on the reservation size.

  • macOS Bug: Toolbar Images Based on SF Symbols Are Vertically Stretched When Displayed on a 1x Display

    Toolbar images based on SF Symbols are vertically stretched when displayed on a 1x display. I filed this as FB12928137, but wanted to let other developers know. This is tricky because the effect is subtle and because developers without a 1x display will not see the issue. I worked around it by exporting the SF Symbols as 37-point images and putting them in PDFs in the asset catalog. I made each image 55x55, and centered the symbol graphic inside it.

    I created a sample project with a Settings window with a toolbar. When displayed on a 1x display, images in the toolbar based on SF symbols get vertically stretched.

    You can see the effect in the Settings windows of Apple apps, including Apple Mail and Messages.

    To reproduce:

    1. Start with a Mac that has both a 1x and 2x display. In my case I have an M2 MacBook Pro 16” with two external 1x displays. The two external displays are VX2239 Series Display (21.5-inch, 1920x1080) and K272HUL Display (27-inch, 2560x1440). I also encounter the issue if I only have either one of the two displays attached.

    2. Download and run this sample app.

    3. Open its Settings window by selecting “Settings…” under the “SwiftUISettingsWindow” menu.

    4. Drag the Settings window to the 2x display if it is not there already.

    5. Observe that the Speedometer icon is a 40x40 (based on pixels) circle.

    6. Drag the Settings window to the 1x display.

    Expected result: I would expect the speedometer to remain a circle.

    Actual result: The speedometer is a 19x22 oval.

    Sample app Settings window on a 2x display: All toolbar icons look as expected.

    Sample app settings window on a 1x display: The “Speedometer” icon is vertically stretched.

    Alternatively:

    1. Open Apple Mail, and select “Settings…” under the “Mail” menu.

    2. Drag the Settings window to the 2x display, if it is not there already.

    3. Observe that the “@” in the Toolbar above “Accounts” looks as expected, and is 41x42 (based on pixels).

    4. Drag the Settings window to the 1x display.

    Expected result: I would expect the “@” symbol to retain its aspect ratio, with the height being identical to or one pixel taller than the width.

    Actual result: The “@” symbol is 20x24. The gear above “General” also looks vertically stretched.

    Mail Settings window on a 2x display: All toolbar icons look as expected.

    Mail Settings window on a 1x display: The “@” toolbar icon is vertically stretched. The toolbar gear icon above “General” is also vertically stretched.

    Notes:

    1. My sample app uses SwiftUI. I initially saw the issue with an AppKit app using an NSToolbar.

    2. My sample app uses the “speedometer” SF Symbol, but the issue is not specific to that SF Symbol.

    3. I do not have a Mac without a built-in 2x display, so I cannot determine whether the bug affects a Mac that has 1x displays but no 2x displays.

    4. When capturing screenshots for this blog post I ran into a situation where I could not reproduce the issue with Apple Mail immediately. It like seemed the problem had disappeared. Then I reproduced the issue again by ensuring that when I first opened the Mail Settings window, I first opened it on the 2x display and then moved it to the 1x display. Opening on the 2x display does not seem to be required for my sample app though.

    Addendum: It later occurred to me that I am assuming 1x is what is triggering the issue. It could just as easily be using any external display (1x or 2x).

    Update August 15, 2023: Thanks to Michael Tsai for linking to this from his blog. He adds some comments and links to related information from Mario Guzmán.

  • I have not taken a test yet, but I am pretty sure I have COVID. Not a fan.

  • March 2023: No former President has ever been indicted before. No one knows what to expect.

    August 2023: Which of his resorts is hosting the arraignment party?

  • I sometimes have to remind myself that I have very rarely regretted a decision to reduce scope of an app or feature.

  • Exciting day. I bought a car, although I don’t have it yet. And I had the fire department at my house.

    All is well. I had a carbon monoxide detector go off, but the problem is just that the carbon monoxide detector went bad.

  • I am in the process of trying to buy a used car, and I am exasperated by the communication skills of some sellers. Basic things like having an appointment scheduled to look at a car, but needing to ask numerous times for the address.

  • Customer Satisfaction Survey: Are you likely to recommend us to others? If not, why?

    Me: No, because…

    Customer Satisfaction Survey: Can we quote you in our marketing materials?

    Me: 🤣

  • I went to WaterFire tonight in Providence, Rhode Island.

    Fires on the Providence River.

  • Congratulations to @harshil@mastodon.social on the launch of Peak, an app that lets you build your personal fitness dashboard.

  • I finally got a chance to check out Polar Park.

    Worcester Red Sox game at Polar Park

  • Zev Eisenberg:

    Learn Swift Boston has a special guest presentation slated for August. That’s over a month away, but why not grab your spot now and put it on your calendar! Come see Mira and Curtis give an intro to dynamic programming, a popular interview topic at FAANG and others. And you don’t need to be in Boston - it’s all online!

    Details on Meetup

  • App Store Connect: Inability to Process Builds of a Mac App Compiled and Uploaded With Xcode 14.3.1 or Xcode 15

    I spent the last three days troubleshooting an issue submitting a Mac app to App Store Connect. The problem appears to be triggered by a subtle change between Xcode 14.3.0 and Xcode 14.3.1. I have this issue when using Xcode 14.3.1 and Xcode 15. My temporary workaround is to submit the app using Xcode 14.3.0. I reported this as FB12418390:

    Submitting a storyboard-based Mac app where the default Window Controller Scene and View Controller Scene are removed from the default storyboard results in an inability of the app to be processed by App Store Connect.

    App Store Connect processing works as expected when the app is compiled and submitted with Xcode 14.3.0, but not with Xcode 14.3.1 or the current Xcode 15 beta releases. After submitting such an app with Xcode 14.3.1 or later, the upload appears to work. But then I get an email saying that processing failed because of an invalid signature (ITMS-90238) and because sandboxing is not enabled (ITMS-90296).

    To reproduce:

    1. Create a storyboard-based Mac app with Xcode.

    2. Take the necessary steps to submit it to App Store Connect (icons, provisioning profiles, etc). But there is no need to add any functionality to the app.

    3. Submit to App Store Connect. Observe that the app can be submitted and processed as expected.

    4. Open the storyboard file and remove the Window Controller Scene and View Controller Scene. Leave only the Application Scene with the Application, App Delegate, Font Manager, and First Responder.

    5. Increment the build number.

    6. Resubmit to App Store Connect.

    Expected result: The app can be uploaded and processed as expected.

    Actual result: This works as expected with Xcode 14.3.0. When built and uploaded with Xcode 14.3.1 and Xcode 15.0 beta 2 (15A5161b), the app can be uploaded but I get an email saying that processing failed because of an invalid signature (ITMS-90238) and because sandboxing is not enabled (ITMS-90296).

    I can also reproduce this with the attached sample project. If I submit this to App Store Connect using Xcode 14.3.1 or Xcode 15.0 beta 2 (15A5161b) it fails as described above.

    I believe this to be a very serious problem. It took me 3 days of trial and error to determine what was triggering the App Store Connect processing failures. I do not know if it is common to remove the default Window Controller Scene and View Controller Scene from the main storyboard. I tend to do this because I like windows to have their own storyboard files. I use the default storyboard just to configure menus in the menu bar.

  • At the New Hampshire Fisher Cats game.

    View of baseball field

  • Widgets and Content Margins

    If you have an app with widgets, be sure to check how the widgets look after compiling with Xcode 15.

    The new .widgetContentMargins are a nice addition, but I found adopting them in a way that allows the widgets to continue working well under iOS 16 to be a significant undertaking.

    The new .contentMarginsDisabled() modifier on WidgetConfiguration is supposed to do nothing on iOS 16, but it makes the widget extension crash on iOS 16. Here is a modifier you can use instead:

    extension WidgetConfiguration {

    func `contentMarginsDisabledOnNewOperatingSystem`() -> some WidgetConfiguration {
        if #available(iOSApplicationExtension 17.0, *) {
            return self.contentMarginsDisabled()
        } else {
            return self
        }
    }

}

    Since .contentMarginsDisabled() is applied at the WidgetConfiguration level, .contentMarginsDisabled() cannot apply to just one size of a widget.

  • Seen while out walking.

    Photo of two deer

  • App: You are not letting me send notifications to your device.

    Me: Correct.

  • He was indicted again. ⚖️

subscribe via RSS