AppClip testing
I have an app with an app clip in TestFlight. I can have testers launch the clip directly from TestFlight but when anyone including me scans a QR code with the correct URL, it comes up as not being available in your country or region. So they can’t launch the clip from the card. Anyone know how to get the AppClip card to appear with the assets in AppConnect and be able to launch the AppClip card from that? Eric (sent from my iPhone) ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: App can't be opened
Thanks a lot for the insight. Best regards, Gabriel smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: App can't be opened
Hey, > On Sep 15, 2021, at 11:38 AM, Gabriel Zachmann via Cocoa-dev > wrote: > > Thanks so much! I guess that missing symbol explains the crash. > > BTW: is it possible, to make Xcode produce an error message when I am using > symbols that are not available on the deployment target? > (unless they are guarded by @available() ...) Normally, that does happen automatically. However, in this case, it appears that AVAudioSessionInterruptionNotification is missing an availability annotation for macOS. The compiler interprets this as meaning “symbol is always available” and doesn’t warn you. Since the online docs say that AVAudioSessionInterruptionNotification only became publicly available in macOS 11.0, I suspect this is a bug in the AVFAudio headers. (This is a somewhat frequent occurrence as iOS APIs get moved over to macOS—often to support Catalyst—without a thorough audit of the headers.) Matt ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Sandboxing for .saver bundles changed in Security Update 2021-005 ?
I am getting a few reports by users of my .saver screensaver bundle that my screensaver no longer works under macOS Mojave 10.14.6. It used to work, so i was wondering if there have been any changes with the sandboxing, perhaps in the latest Security Update 2021-005, wrt. screensavers ? Any insights will be highly appreciated. Best regards, Gabriel smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC and C++ structures
On 15 Sep 2021, at 17:39, Matt Jacobson mailto:mhjacob...@me.com>> wrote: On Sep 15, 2021, at 11:21 AM, Tor Arne Vestbø mailto:tor.arne.ves...@qt.io>> wrote: On 14 Sep 2021, at 16:33, Matt Jacobson via Cocoa-dev mailto:cocoa-dev@lists.apple.com>> wrote: By default, when an NSWindow is `-close`d (which can only happen once in its lifetime), Interesting. If the NSWindow is retained elsewhere, can it not be ordered in again? Appreciate any details you can provide :) I was wrong about this detail. The window can definitely be ordered in again, and any subsequent `-close` does *not* issue a `-release`, even if the window `isReleasedWhenClosed`. (How confusing.) Thanks for the clarification! Cheers, Tor Arne ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC and C++ structures
> On Sep 15, 2021, at 11:21 AM, Tor Arne Vestbø wrote: > > >> On 14 Sep 2021, at 16:33, Matt Jacobson via Cocoa-dev >> mailto:cocoa-dev@lists.apple.com>> wrote: >> >> By default, when an NSWindow is `-close`d (which can only happen once in its >> lifetime), > > Interesting. If the NSWindow is retained elsewhere, can it not be ordered in > again? Appreciate any details you can provide :) I was wrong about this detail. The window can definitely be ordered in again, and any subsequent `-close` does *not* issue a `-release`, even if the window `isReleasedWhenClosed`. (How confusing.) So ignore the parenthetical part, but do `setReleasedWhenClosed:NO` your windows. Matt ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: App can't be opened
Thanks so much! I guess that missing symbol explains the crash. BTW: is it possible, to make Xcode produce an error message when I am using symbols that are not available on the deployment target? (unless they are guarded by @available() ...) Best regards, Gabriel > On 9. Sep 2021, at 20:30, Carl Hoefs wrote: > > On a 10.13 system, your app gives this in the console log: > > opendirectoryd: Authentication failed for with result > ODErrorCredentialsInvalid > opendirectoryd: ODRecordVerifyPassword failed with result > ODErrorCredentialsInvalid > > The (extensive) crash log has this at the top: > > Crashed Thread:0 > > Exception Type:EXC_CRASH (SIGABRT) > Exception Codes: 0x, 0x > Exception Note:EXC_CORPSE_NOTIFY > > Termination Reason:DYLD, [0x4] Symbol missing > > Application Specific Information: > dyld: launch, loading dependent libraries > > Dyld Error Message: > Symbol not found: _AVAudioSessionInterruptionNotification > Referenced from: /Applications/ArtSaverApp.app/Contents/MacOS/ArtSaverApp > Expected in: > /System/Library/Frameworks/AVFoundation.framework/Versions/A/AVFoundation > in /Applications/ArtSaverApp.app/Contents/MacOS/ArtSaverApp > > -Carl > smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC and C++ structures
On 14 Sep 2021, at 16:33, Matt Jacobson via Cocoa-dev mailto:cocoa-dev@lists.apple.com>> wrote: By default, when an NSWindow is `-close`d (which can only happen once in its lifetime), Interesting. If the NSWindow is retained elsewhere, can it not be ordered in again? Appreciate any details you can provide :) Cheers, Tor Arne ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC and C++ structures
Thanks. That did it. Interestingly, not only did the Applie Migration
tool not flag a potential problem, but the docs on NSWindow and
releaseWhenClosed don't even hint of it.
> Hi Tom,
>
> > On Sep 14, 2021, at 9:53 AM, Tom Doan via Cocoa-dev
> > wrote:
> >
> > I have a multiple platform application (Windows, Mac, GTK) that is
> > primarily organized using C++ with Objective-C used for the
> > Mac-specific interface. I recently switched to use ARC (as we are
> > using Scintilla which recently switched to ARC). However, I am
> > getting a zombied release of an NSWindow instance. So far as I can
> > tell, the memory handling of this seemed to be fine pre-ARC.
> > Unfortunately, because it's an NSWindow, the Instruments output for
> > it has 100's of toolbox calls, so it's very hard to tell where the
> > extra release is. What should I be looking for?
> >
> > Just to describe this, there's an EWindow C++ structure which has
> > the NSWindow * as a member (under Mac OS; it's an HWND under Windows
> > and Widget under GTK). It's after the delete of the EWindow that
> > things go south. I'm assuming that ARC is putting in a release, but
> > I haven't really seen any good description of how ARC interacts with
> > C++. A release there seems fine---the question is where is the
> > earlier (apparently erroneous) release.
>
> ARC will insert code at the end of your C++ destructor to release any
> strong id members.
>
> One possible wrinkle is the default release-when-close behavior of
> NSWindow. By default, when an NSWindow is `-close`d (which can only
> happen once in its lifetime), AppKit sends it a `-release`. The idea
> is that this release balances the initial `+alloc`.
>
> However, this is somewhat incompatible with ARC, which doesn´t know
> about this special behavior and will attempt to insert its own release
> to balance the alloc.
>
> Here is an example of a program that works perfectly fine under MRR
> but crashes under ARC:
>
> #import
>
> NSWindow *window;
>
> int main(void) {
> @autoreleasepool {
> window = [[NSWindow alloc]
> initWithContentRect:NSMakeRect(0., 0., 100.,
> 100.) styleMask:NSWindowStyleMaskTitled
> backing:NSBackingStoreBuffered defer:NO];
> [window makeKeyAndOrderFront:nil]; [window
> close]; window = nil;
> }
> }
>
> You can disable this behavior by changing the `releasedWhenClosed`
> property of the window to `NO`:
>
> [window setReleasedWhenClosed:NO];
>
> Matt
>
---
2717 Harrison St
Evanston, IL 60201
USA
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
