Date   

Re: Multiple versions of an app

Alex Zavatone
 

On Dec 17, 2020, at 7:03 PM, James Walker <list2@jwwalker.com> wrote:



On Dec 16, 2020, at 12:41 PM, Carl Hoefs <newslists@autonomy.caltech.edu> wrote:

On Dec 16, 2020, at 12:16 PM, Alex Zavatone via groups.io <zav=mac.com@groups.io> wrote:

Duplicate the target 7 times and change the bundle ID for each.
How to do duplicate a target (and rename it)? The Duplicate menu item has been removed.
I still see Duplicate on the menu that pops up when I right-click a target.

That’s what I’ve used..


Re: Multiple versions of an app

James Walker
 

On Dec 16, 2020, at 12:41 PM, Carl Hoefs <newslists@autonomy.caltech.edu> wrote:

On Dec 16, 2020, at 12:16 PM, Alex Zavatone via groups.io <zav=mac.com@groups.io> wrote:

Duplicate the target 7 times and change the bundle ID for each.
How to do duplicate a target (and rename it)? The Duplicate menu item has been removed.
I still see Duplicate on the menu that pops up when I right-click a target.


Re: Multiple versions of an app

Alex Zavatone
 

A better explanation is that the info.plist uses that build setting, that environment variable as the name of the executable.  

There’s a little relationship between $(TARGET_NAME), $(PRODUCT_NAME) and $(EXECUTABLE_NAME).  These are defined in your target’s build settings and used in various places, such as our friendly info.plist.

These are good resources to help you make sense of them. Expect a few to be missing.


Make sure to save this as a PDF for future reference.

Looking forward ti hearing about the end result of this product you’re creating.

Alex Zavatone

On Dec 16, 2020, at 6:15 PM, Carl Hoefs <newslists@...> wrote:

Yes - $(TARGET_NAME) is the correct identifier! 

Setting this also changes the executable name under ../MacOS and CFBundleName and CFBundleExecutable in the Info.plist.

Thx!
-Carl


On Dec 16, 2020, at 1:58 PM, Alex Zavatone via groups.io <zav@...> wrote:

That’s in your Build Settings 

$(TARGET_NAME)

<PastedGraphic-2.png>

On Dec 16, 2020, at 3:56 PM, Carl Hoefs <newslists@...> wrote:

On Dec 16, 2020, at 1:33 PM, Carl Hoefs <newslists@...> wrote:

in project settings:

BUNDLE_ID_SEQ="0"
PRODUCT_BUNDLE_IDENTIFIER="com.example.foo.$(BUNDLE_ID_SEQ)"

then:

$ xcodebuild BUNDLE_ID_SEQ=1
(etc.)


Could this way also be used to name the app itself? 

Something like: PRODUCT_EXECUTABLE_NAME="MyApp$(BUNDLE_ID_SEQ)"
to generate MyApp1.app, MyApp2.app, etc...

-Carl





Re: Multiple versions of an app

Sandor Szatmari
 

What about using NSUserDefaults -addSuiteNamed:


Could you add subdomains for each of the areas for which you need to main discrete defaults?

Then manage each ‘suite’ in it’s own thread/subprocess etc

Then you could have one app, partitioned into subdomains internally.  I’m seeing a tabbed interface?

Sandor

On Dec 16, 2020, at 14:43, Carl Hoefs <newslists@...> wrote:

Xcode 11.3.1 / macOS 10.14.6

I've written a small macOS app that performs user-configurable statistics over the course of days. It works fine, but I need to be able to run 8 such identical apps simultaneously. Each app needs its own unique bundle identifier (for settings/defaults, window placement, etc).

How can I use Xcode to produce 8 simultaneously runnable versions of my app? Or would it be more expedient to simply twiddle the Info.plist of copies of the app?

-Carl







Re: Multiple versions of an app

Carl Hoefs
 

Yes - $(TARGET_NAME) is the correct identifier! 

Setting this also changes the executable name under ../MacOS and CFBundleName and CFBundleExecutable in the Info.plist.

Thx!
-Carl


On Dec 16, 2020, at 1:58 PM, Alex Zavatone via groups.io <zav@...> wrote:

That’s in your Build Settings 

$(TARGET_NAME)

<PastedGraphic-2.png>

On Dec 16, 2020, at 3:56 PM, Carl Hoefs <newslists@...> wrote:

On Dec 16, 2020, at 1:33 PM, Carl Hoefs <newslists@...> wrote:

in project settings:

BUNDLE_ID_SEQ="0"
PRODUCT_BUNDLE_IDENTIFIER="com.example.foo.$(BUNDLE_ID_SEQ)"

then:

$ xcodebuild BUNDLE_ID_SEQ=1
(etc.)


Could this way also be used to name the app itself? 

Something like: PRODUCT_EXECUTABLE_NAME="MyApp$(BUNDLE_ID_SEQ)"
to generate MyApp1.app, MyApp2.app, etc...

-Carl




Re: Multiple versions of an app

Ben Kennedy
 

On 16 Dec 2020, at 1:56 pm, Carl Hoefs <newslists@autonomy.caltech.edu> wrote:

Could this way also be used to name the app itself?

Something like: PRODUCT_EXECUTABLE_NAME="MyApp$(BUNDLE_ID_SEQ)"
to generate MyApp1.app, MyApp2.app, etc...
Good point; you should be able to achieve that by changing PRODUCT_NAME.

-ben


Re: Multiple versions of an app

Alex Zavatone
 

That’s in your Build Settings 

$(TARGET_NAME)



On Dec 16, 2020, at 3:56 PM, Carl Hoefs <newslists@...> wrote:

On Dec 16, 2020, at 1:33 PM, Carl Hoefs <newslists@...> wrote:

in project settings:

BUNDLE_ID_SEQ="0"
PRODUCT_BUNDLE_IDENTIFIER="com.example.foo.$(BUNDLE_ID_SEQ)"

then:

$ xcodebuild BUNDLE_ID_SEQ=1
(etc.)


Could this way also be used to name the app itself? 

Something like: PRODUCT_EXECUTABLE_NAME="MyApp$(BUNDLE_ID_SEQ)"
to generate MyApp1.app, MyApp2.app, etc...

-Carl



Re: Multiple versions of an app

Carl Hoefs
 

On Dec 16, 2020, at 1:33 PM, Carl Hoefs <newslists@...> wrote:

in project settings:

BUNDLE_ID_SEQ="0"
PRODUCT_BUNDLE_IDENTIFIER="com.example.foo.$(BUNDLE_ID_SEQ)"

then:

$ xcodebuild BUNDLE_ID_SEQ=1
(etc.)


Could this way also be used to name the app itself? 

Something like: PRODUCT_EXECUTABLE_NAME="MyApp$(BUNDLE_ID_SEQ)"
to generate MyApp1.app, MyApp2.app, etc...

-Carl


Re: Multiple versions of an app

Alex Zavatone
 



On Dec 16, 2020, at 3:18 PM, Jack Brindle via groups.io <jackbrindle@...> wrote:

Now, if you really want eight individual apps, create a single parent-app that contains the individual apps, launching them as needed (NSTask will do the job quite well). 

An awesome thing to do if you want to use NSTask is to check if there are any other instances of the app running.  I use a shell script to check if the PID exists.  If there aren’t, then one app automatically launches all the rest through either NSTask or a shell script.

The same shell script that I used before or a look as mentioned can be used to build the name and launch the other apps.

open /Applications/Carl-o-matic-1.app;
open /Applications/Carl-o-matic-2.app;
open /Applications/Carl-o-matic-3.app;
open /Applications/Carl-o-matic-4.app;
open /Applications/Carl-o-matic-5.app;
open /Applications/Carl-o-matic-6.app;
open /Applications/Carl-o-matic-7.app;
open /Applications/Carl-o-matic-8.app;
 
There are lots of ways to do this, but IMHO, the apps will have known names, just do it the easy way and open them instead of writing too much code.

Ben’s idea for the build is nice and crafty.  You can have a custom build scheme to handle that pretty nicely.

Alex Zavatone


Re: Multiple versions of an app

Alex Zavatone
 


OK.  So, here’s how to launch them through an AppleScript.

on run
do shell script "open /Applications/Carl-o-matic-1.app;
open /Applications/Carl-o-matic-2.app;
open /Applications/Carl-o-matic-3.app;
open /Applications/Carl-o-matic-4.app;
open /Applications/Carl-o-matic-5.app;
open /Applications/Carl-o-matic-6.app;
open /Applications/Carl-o-matic-7.app;
open /Applications/Carl-o-matic-8.app;"
end run


Since they all have a different bundle and name, you wouldn’t need the -n argument then.

If you really needed to, you could build the name from a loop and launch them all.  

Cheers,
Alex Zavatone


On Dec 16, 2020, at 2:41 PM, Carl Hoefs <newslists@...> wrote:

On Dec 16, 2020, at 12:16 PM, Alex Zavatone via groups.io <zav@...> wrote:

Duplicate the target 7 times and change the bundle ID for each.

How to do duplicate a target (and rename it)? The Duplicate menu item has been removed.

Is there a reason why you can’t open one copy of the app with a
parameter?

Each app has its own settings and defaults, so I can't just run one 8 times. Each needs its own unique bundle identifier.

-Carl








Re: Multiple versions of an app

Carl Hoefs
 

On Dec 16, 2020, at 1:00 PM, Ben Kennedy <ben-groups@zygoat.ca> wrote:

On 16 Dec 2020, at 11:43 am, Carl Hoefs <newslists@autonomy.caltech.edu> wrote:

How can I use Xcode to produce 8 simultaneously runnable versions of my app? Or would it be more expedient to simply twiddle the Info.plist of copies of the app?
How about defining a new build setting and injecting that into the bundle identifier, then passing its value on the command line?

in project settings:

BUNDLE_ID_SEQ="0"
PRODUCT_BUNDLE_IDENTIFIER="com.example.foo.$(BUNDLE_ID_SEQ)"

then:

$ xcodebuild BUNDLE_ID_SEQ=1
(etc.)
Yes! This is sheer genius! Works perfectly!

Thanks Ben!
-Carl


Re: Multiple versions of an app

Jack Brindle
 

There are several ways to do this. I don’t think you want to build eight separate Mac apps - it would require eight Notarization passes, which, at 5 to 10 minutes per pass, will take an hour or more just for the build.

Instead, I would find a way to consolidate the functions into a single app, with separate UIs for each function. That way the app is built once, run once, removed once, etc., making it much easier on the user.

Now, if you really want eight individual apps, create a single parent-app that contains the individual apps, launching them as needed (NSTask will do the job quite well). You might even be able to use a single embedded app, passing in command line arguments to customize the operation of each one. As for the preferences, there is no requirement that the system handle the app’s preferences. You can certainly create your own settings facility that saves the data to a file (located in ~/Library/preferences). Again, the command-line argument can tell the app which settings file to use.

This sounds like a fun little project (key word is little), similar to several I have created over the years. Making multiple target applications can be and usually is a pain, but proper application design will take a situation of this sort and make it much more elegant.

Good luck!
Jack

On Dec 16, 2020, at 11:43 AM, Carl Hoefs <newslists@autonomy.caltech.edu> wrote:

Xcode 11.3.1 / macOS 10.14.6

I've written a small macOS app that performs user-configurable statistics over the course of days. It works fine, but I need to be able to run 8 such identical apps simultaneously. Each app needs its own unique bundle identifier (for settings/defaults, window placement, etc).

How can I use Xcode to produce 8 simultaneously runnable versions of my app? Or would it be more expedient to simply twiddle the Info.plist of copies of the app?

-Carl






Re: Multiple versions of an app

Ben Kennedy
 

On 16 Dec 2020, at 11:43 am, Carl Hoefs <newslists@autonomy.caltech.edu> wrote:

How can I use Xcode to produce 8 simultaneously runnable versions of my app? Or would it be more expedient to simply twiddle the Info.plist of copies of the app?
How about defining a new build setting and injecting that into the bundle identifier, then passing its value on the command line?

in project settings:

BUNDLE_ID_SEQ="0"
PRODUCT_BUNDLE_IDENTIFIER="com.example.foo.$(BUNDLE_ID_SEQ)"

then:

$ xcodebuild BUNDLE_ID_SEQ=1
(etc.)

-ben


Re: Multiple versions of an app

Carl Hoefs
 

On Dec 16, 2020, at 12:16 PM, Alex Zavatone via groups.io <zav=mac.com@groups.io> wrote:

Duplicate the target 7 times and change the bundle ID for each.
How to do duplicate a target (and rename it)? The Duplicate menu item has been removed.

Is there a reason why you can’t open one copy of the app with a -n parameter?
Each app has its own settings and defaults, so I can't just run one 8 times. Each needs its own unique bundle identifier.

-Carl


Re: Multiple versions of an app

Alex Zavatone
 

Duplicate the target 7 times and change the bundle ID for each.

You can also make a build operation that builds more than one target.  

Or just issue this script.
xcodebuild -project projName -alltargets
Or this one.

xcodebuild -target appCopy1 -target appCopy2

Is there a reason why you can’t open one copy of the app with a -n parameter?  You can build a script that does this 8 times to launch 8 copies of 1 app.

You could have an app as an AppleScript app to issue a shell script to do it.

on run
do shell script "open -n /Applications/Utilities/Terminal.app;
open -n /Applications/Utilities/Terminal.app;
open -n /Applications/Utilities/Terminal.app;
open -n /Applications/Utilities/Terminal.app;"
end run


Cheers,
Alex Zavatone


On Dec 16, 2020, at 1:43 PM, Carl Hoefs <newslists@...> wrote:

Xcode 11.3.1 / macOS 10.14.6

I've written a small macOS app that performs user-configurable statistics over the course of days. It works fine, but I need to be able to run 8 such identical apps simultaneously. Each app needs its own unique bundle identifier (for settings/defaults, window placement, etc).

How can I use Xcode to produce 8 simultaneously runnable versions of my app? Or would it be more expedient to simply twiddle the Info.plist of copies of the app?

-Carl








Multiple versions of an app

Carl Hoefs
 

Xcode 11.3.1 / macOS 10.14.6

I've written a small macOS app that performs user-configurable statistics over the course of days. It works fine, but I need to be able to run 8 such identical apps simultaneously. Each app needs its own unique bundle identifier (for settings/defaults, window placement, etc).

How can I use Xcode to produce 8 simultaneously runnable versions of my app? Or would it be more expedient to simply twiddle the Info.plist of copies of the app?

-Carl


Re: Accessing instance variables: Xcode warnings

James Walker
 

On Dec 14, 2020, at 4:08 PM, Jens Alfke <jens@mooseyard.com> wrote:



On Dec 11, 2020, at 12:33 PM, Alex Zavatone via groups.io <zav=mac.com@groups.io> wrote:

_mType is the internal class scoped copy of it.

self. is safest. It’s wrapped with the get and set accessors.
It's not that much safer, really. There's no difference in single-threaded code. If the property is being read and written on multiple threads, and you declare the property @atomic, the getter and setter will be thread-safe while the direct read/write can in some cases crash. (But only if it's an object pointer, not a scalar.)

In most cases, inside the class implementation I [used to] just access the ivar directly because it's a lot faster and produces smaller code.

Setting the instance variable directly will not be reported to KVO observers. Sometimes that may be what you want, other times not.


Re: Accessing instance variables: Xcode warnings

 



On Dec 11, 2020, at 12:33 PM, Alex Zavatone via groups.io <zav@...> wrote:

_mType is the internal class scoped copy of it.

self. is safest.  It’s wrapped with the get and set accessors.

It's not that much safer, really. There's no difference in single-threaded code. If the property is being read and written on multiple threads, and you declare the property @atomic, the getter and setter will be thread-safe while the direct read/write can in some cases crash. (But only if it's an object pointer, not a scalar.)

In most cases, inside the class implementation I [used to] just access the ivar directly because it's a lot faster and produces smaller code.

—Jens


Re: Accessing instance variables: Xcode warnings

Chris Hanson
 

On Dec 11, 2020, at 11:02 AM, Carl Hoefs <newslists@...> wrote:

I have an ObjC class that has an instance variable "property" declared as such:

@property (nonatomic,retain,nonnull) NSString *mType;

This is not an instance variable, this is a property. In Objective-C, like Smalltalk, an instance variable is usually part of the internal implementation of your class. That's why as of Objective-C 2.0 and the new runtime, they can (and should) be declared in the @implementation instead fo the @interface.

(I'd also not name a property something like "mType," but give it a more semantic name.)

In a instance method of this class, I can refer to mType in various ways, with warnings:

mType "Instance variable 'mType' is being directly accessed"

This will be the name of the instance variable providing storage for the property if your `@implementation` has `@synthesize mType;`.

_mType "Use of undeclared identifier '_mType'; did you mean 'mType'?"

This will be the name of the instance variable providing storage for the property if you either have no `@synthesize` for it, or if you have `@synthesize mType = _mtype;` in your `@implementation`.

self.mType (No warning, but is very slow if used in a loop. Needed for blocks)

This is interacting with the property via its accessors, not accessing its storage.

Q1: "Direct" access to an instance variable bypasses its setter/getter methods, but otherwise what is wrong with it?

It all depends what you want. Often in the implementation of a class you know what the invariants you need to maintain are, so you can interact directly with the backing storage for a property. Note that this doesn't have to be an instance variable, that's just the default behavior.

Q2: Sometimes using the underscore form, _mType, quiets the direct access warning; other times Xcode acts like it doesn't know what I'm referring to. What is the underscore intended for?

See above.

Yes I can turn the Xcode warnings off by deleting -Weverything, but I want to do the right thing...

What's right will depend on both context and an understanding of the distinction between the property (an interface) and its underlying storage (an implementation). You can usually 

  -- Chris



Re: NSData -writeToFile: returns FALSE

Jon Gotow
 

Yeah, that's part of the TCC (transparency, consent and control) privacy stuff in Mojave and higher. Without Full Disk Access, your app is prevented from accessing some filesystem locations unless it has been explicitly or implicitly allowed by the user. That means that you're given an access right if you use an Open or Save As dialog to prompt the user to select a file or location, or if you ask the system for a temp folder for use by your app (AFAIK, you're not allowed to generically read or write to /tmp because that might allow you to see other applications' temp files). Oh - or if the user implicitly permits access by dragging or double-clicking a file to open it.

Apple has ratcheted up the number of folders that are protected this way in the last few OS releases. Mojave was fairly permissive - it only refused to let you see Contacts, Calendar, Messages, Photos, Mail and Safari folders, I think. Catalina added Desktop, Documents, Downloads, iCloud Drive and removable volumes, which ends up impacting a lot more software.

- Jon

On Dec 10, 2020, at 7:17 PM, Carl Hoefs <newslists@autonomy.caltech.edu> wrote:

Interesting idea. That worked! I never knew that "Full Disk Access" even existed.

-Carl


On Dec 10, 2020, at 5:58 PM, Jon Gotow <gotow@stclairsoft.com> wrote:

Just out of curiosity - go to System Preferences > Security & Privacy > Full Disk Access, click on the padlock in the lower left corner to unlock, then drag your app to the list. Does that fix things?

- Jon


On Dec 10, 2020, at 6:54 PM, Carl Hoefs <newslists@autonomy.caltech.edu> wrote:

On Dec 10, 2020, at 5:16 PM, Shane Stanley <sstanley@myriad-com.com.au> wrote:

On 11 Dec 2020, at 11:59 am, Carl Hoefs <newslists@autonomy.caltech.edu> wrote:

Adding NSDesktopFolderUsageDescription forces the addition of a provisioning profile, et al.
No it doesn't. It's a simple Info.plist entry.
Ah, yes, you're right. I had added it to the .entitlements file.

I added it to the Info.plist file but no change in behavior...

-Carl


141 - 160 of 1432