Re: ARC

[Owen Hartnett via Cocoa-dev]

Also turn on Zombie Objects and the other diagnostic features in Xcode edit 
Scheme -> Diagnostics.

-Owen

> On Aug 26, 2019, at 1:43 PM, Jean-Daniel via Cocoa-dev 
>  wrote:
> 
> A better way to investigate such issue is using the memory debugging tools in 
> Instrument IMHO.
> That would let you see all stack traces of retain/release calls.
> 
>> Le 26 août 2019 à 04:14, Turtle Creek Software via Cocoa-dev 
>>  a écrit :
>> 
>> In GSAppDelegate.h
>> GSOutlineWindowController *mainWindowController;
>> 
>> In GSAppDelegate.mm
>> - (void) showOutlineWindow
>> {
>>if (mainWindowController == NULL)
>> mainWindowController = [[GSOutlineWindowController alloc]
>> initWithWindowNibName : @"GSOutlineWindowController"];
>>[mainWindowController showWindow : self];
>> }
>> 
>> We don't do any ref-counting at all.  A search for CFRetain and CFRelease
>> showed zero items.
>> 
>> I would say that ARC is certainly way better than the previous manual
>> ref-counting.  That must have been hellish.
>> Fortunately we only started the Carbon->Cocoa port 3 years ago, so we
>> didn't need to retain/release.
>> But we have wasted at least a month, tracking down mysterious object
>> deletions that theoretically should not happen.
>> 
>> At this point we pretty much have breakpoints on dealloc() for every
>> class.  That lets us know when something is
>> dying, but gives no clue as to why.  Breakpoints on release() go deep into
>> Apple Assembly code.
>> 
>> On Sun, Aug 25, 2019 at 12:42 PM Jens Alfke  wrote:
>> 
>>> 
 On Aug 24, 2019, at 4:46 AM, Turtle Creek Software <
>>> supp...@turtlesoft.com> wrote:
 
 Our app delegate class is not deallocated.  The window controller is
>>> deallocated
 despite the member reference there.
>>> 
>>> That should not be possible. Could you paste the exact line of code that
>>> declares the window-controller reference in the app delegate?
>>> 
>>> Have you verified that, at the point when the controller is dealloced, the
>>> reference in the app delegate is still non-nil? (I sometimes find it useful
>>> to set a breakpoint in the dealloc method, in weird cases like this.)
>>> 
>>> Do you have any remaining code that messes with ref-counting, I.e. by
>>> using CFRetain/Release on Obj-C objects?
>>> 
>>> —Jens
>>> 
>>> (And let me chime in that ARC is an excellent feature. Cocoa used to have
>>> ‘true’ garbage collection as an option, but it was rarely used on Mac due
>>> to memory and performance impact, and never implemented on iOS for that
>>> reason. ARC works much better. Swift memory management is based on ARC, so
>>> it’s definitely the way of the future.)
>>> 
>> ___
>> 
>> 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/mailing%40xenonium.com
>> 
>> This email sent to mail...@xenonium.com
> 
> ___
> 
> 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/owen%40clipboardinc.com
> 
> This email sent to o...@clipboardinc.com

___

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: Future of Cocoa

[Owen Hartnett via Cocoa-dev]

> On Nov 21, 2019, at 5:49 PM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> 
>> 
>> If someone can afford days/weeks to do watch WWDC sessions consistently
>> every year it's great. That's not a luxury all of us can afford and it's
>> ridiculous to think this should be a requirement.
>> 
> 
> But then, I am wondering, how does your company ensure your programmers 
> stay up-to-date?
> I have a hard time seeing how programmers can remain productive especially in 
> these days where innovation (new frameworks, new tools, new programming 
> languages) is so fast.
> 
> 

As a programmer, I do the following:

1) Keep actively coding.
2) Adopt new technologies as the times and means allow*
3) Specialize in Apple software environment.  Not enough time to do more than 
that.
4) Participate in a Mac/iOS programming meetup group
5) Watch every second of relevant WWDC videos on the train to and from work.

The reason I hitched my wagon to Apple’s star was that it was hard.  It never 
was easy to program Macs, and now devices.  Guys who can code for the hard 
stuff get the top dollar. 
Nobody will pay big bucks for a great BASIC programmer.  Or HTML, or python. 
(No shade on these platforms, they’re just …easier)

-Owen

*I’m easing my way into Swift, basically a class at a time.

-O

___

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: Question about Info.plist's

[Owen Hartnett via Cocoa-dev]

You can also use a build script that calls PlistBuddy to alter the contents of 
a plist called using a Run Script in Build Phases just before Compile Sources.  
I used to use one to apply the subversion revision number to the build version, 
but then I switched to git.


-Owen

> On Aug 19, 2020, at 12:44 PM, Glenn L. Austin via Cocoa-dev 
>  wrote:
> 
> No, you can't use an "earlier" key to create a "later" value - but you can 
> use code to do basically the same thing.
> 
> Or, you can use the same variable that sets your CFBuildNumber to set your 
> CFBundleVersion.
> 
> --
> Glenn L. Austin, Computer Wizard and Race Car Driver <><
> 
> 
>> On Aug 19, 2020, at 9:07 AM, Gabriel Zachmann via Cocoa-dev 
>>  wrote:
>> 
>> Question:
>> 
>> Is there a way to use a key/value that was defined earlier in the plist file
>> to define a value for a later key?
>> 
>> Explanation:
>> I have a macOS project with an automatically created "About" window.
>> The plist file has, additionally to all the default stuff, the key 
>> CFBuildNumber (with a value that I increment automatically).
>> 
>> In Xcode, I tried to change "Bundle version" to a value like
>> 
>>  $(CURRENT_PROJECT_VERSION)_$(CFBuildNumber)
>> 
>> However, in the final Info.plist in the app's bundle, this then looks like
>> 
>>   CFBundleVersion
>>   3.1_
>> 
>> Notice the underscore, but the value of CFBuildNumber is gone.
>> "3.1", BTW, is the value I have set under
>> 
>>   Project / Targets / General / Identity / Build
>> 
>> I have tried to change parentheses into curly braces, to no avail.
>> 
>> So, question again: is there a way to use a key/value that was defined 
>> earlier in the plist file
>> to define a value for a later key?
>> I'd like to do that so that the "About" window contains the build number, 
>> too.
>> 
>> Thanks a lot in advance.
>> 
>> 
>> ___
>> 
>> 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/glenn%40austinsoft.com
>> 
>> This email sent to gl...@austinsoft.com
> 
> ___
> 
> 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/owen%40clipboardinc.com
> 
> This email sent to o...@clipboardinc.com

___

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

Question about certificates and provisioning profiles for enterprise

[Owen Hartnett via Cocoa-dev]

We have an imminent expiration on one of our certificates (29 days).  We use 
“Automatically manage signing."

If we look at the .ipa file for our app, we see that we have three 
certificates.  I guess we created some others.

If I revoke the soon to be expiring certficiate, is there a chance that the app 
will fail because the provisioning profile relied upon the expiring 
certificate? Docs seem to indicate that a provisioning profile is joined with 
one certificate, but since it’s automatically managed, I don’t even see the 
profile anymore (I suppose it’s in DerivedData, so I can’t tell if the profile 
is joined to a good cert.

Since we’re enterprise, revoking a cert could cause immediate invalidation of 
our app.  

Or will the mechanism realize there are other certs in the profile, and match 
up with a valid one?

-Owen
___

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