App Store rejection for app built with 2018r4

Can anyone throw any light on this Mac App Store rejection? I have submitted two different builds and both have been rejected with the following issue.

Both builds were built with 2018r4. Previous versions of this app, built with previous versions of Xojo, have always been accepted, so I’m suspicious this is something to do with Dark Mode. The problem is that I can’t recreate the problem on my machine.

Has anyone successfully submitted a Mac app, built with r4?

Are you using Layer backed views?

I would like Xojo to chime in on this.

The only mention I could find on this error message was for a crash in XCode. Have the testers said how they managed to crash your apps? Do you use any Sam-style declares? Do you have a link to your apps for testing?

Hi Sam, no, at least not directly. This is an incremental update to Server Ranger 2. It is recompiled with 2018r4 for Dark Mode support but there are no other large changes.

They claim it’s crashing upon on launch with the message above: “The window has been marked as needing another Layout Window pass, but it has already had more Layout Window passes than there are views in the window.” There are no new declares in this update, it’s mainly just Dark Mode support.

Problem is, I can’t recreate it. I’ve tried several versions of macOS, I’ve tried my 2018 MacBook Air and my 2017 iMac, I’ve tried a clean VM, I see no crashing. So whatever tools they are running to monitor their testing is picking up on something that I just have no way of debugging.

So again, I’d love to hear from someone who has successfully submitted an app to the MAS, just for my reassurance that it’s not something in the framework.

Since 2018r3 also has Dark Mode support, what would happen if you compiled with that version and submitted?

Yesterday my app “Contract Manager” (build with 2018R4) was released on the AppStore.

Are you suggesting that declares written in my style are culprits for crashes? :wink:

Do you have any declares that reference “appearance”? Or use any plugins for interface goodies?

So a bit of Googling and it appears to be coming from Mojave, I see different responses claim to fix it; but they’re conflicting. Some say enabling layer-backed views solves it, while others are saying to disable layer-backed views to solve it. My feeling is that this is a bug, where it reaches an edge case and fills it’s pants. I’m at the wrong computer, but I’ll share you a declare that you can use to force layer-backed views on, you can try using it to turn it off, but in most cases I’ve found that something else will turn it back on for you.

A word of warning however is that enabling layer-backed views; can lead to certain interface elements adopting the more vibrant style on a dark interface.

You can use the following declares to turn it on and off for the main view within a window, normally the children controls will adopt the parents setting, however it’s more than possible for a child not to follow the parent.

[code]declare Function NSWindowContentView lib “AppKit” selector “contentView” (NSWindowInstance as integer) as integer
declare Sub NSViewWantsLayer lib “AppKit” selector “setWantsLayer:” (NSViewInstance as integer, assigns value as boolean)

NSViewWantsLayer( NSWindowContentView( me.handle ) ) = true[/code]

If you want to tell if a control is layer-backed, you can use the following declare; but don’t make the assumption that if the main view of a window isn’t layer-backed, then nothing is.

declare function NSViewWantsLayer lib "AppKit" selector "wantsLayer" ( NSViewInstance as integer ) as boolean msgbox "Using layer backed views: " + if( NSViewWantsLayer( rectControl.handle ), "YES", "NO" )

I have a sneaking suspicion that Mojave maybe turning this on automagically, and it’s potentially leading to some kind of refresh loop.

There’s two things I can think of right now.

  1. How do you update the interface elements? Make sure that they do not update/refresh/invalidate each other.
  2. In recent years to overcome some nasty visual glitches with modern macOS, I never directly “show” a complex window. Instead I stick it in a queue and fire a timer, which in turn then calls window.show. The interval is 0.16 seconds, but it’s enough time for the macOS to handle it’s shit before the window is attempted to be drawn on screen. It’s an ugly hack to an ugly problem.

I see Apple approved the update, what was the problem and how did you solve it?

The answer is that I honestly don’t know exactly what worked in the end. They rejected it three times for the same issue: The window has been marked as needing another Layout Window pass, but it has already had more Layout Window passes than there are views in the window.

I was getting worried about the number of rejections and didn’t want to keep trying and getting rejected in case they got fed up, so I spent half a day cleaning up paint events and working hard at only refreshing when absolutely necessary and only the areas that needed refreshing etc etc etc. Something worked as it was finally approved in 6 minutes during the fourth review.