Date   

DMG Notarization

Marco S Hyman
 

A user informed me that he couldn’t install my app on the Catalina beta. I believe the issue is that even though my app is notarized, the dmg file is not. Does anyone have experience in getting a dmg notarized? Any pointers?

I’ve found some instructions on doing the job using xcrun altool which could, I think, be easily integrated into my dmg build script except for three things:

1) I need to provide a --primare-bundle-id. Is this something I make up for the dmg or the bundle ID of the included app?

2) and 3) is there a way to provide username and password without storing them in the script?


TIA,

Marc


Debug Memory Graph

Alex Zavatone
 

Does anyone know if there is a way to programmatically invoke the Debug Memory Graph from code?

I’d like to bring it up automatically at the end of a test run.

Hanks in advance,
Alex Zavatone


Diffing the results of heap.

Alex Zavatone
 

I’ve been looking the complete memory hell of our iOS app and in getting it under control, have been expanding UITest to run multiple iterations of the whole tests, tracking memory used between tests due to a lovely post by Quinn and slowly unraveling our “let’s use strong links for every object instance while we use a development model that we do not understand” product *architecture*.

Since we can now dump out memory use that matches what is in Xcode’s Debug Navigator and each test can run more than one time, we have an opportunity to measure the objects allocated during each test iteration.

And thus I turn to the heap terminal command which outputs just that.

But since I can set up the test runs to run each test more than once, it would seem that one could diff the output of certain parts of heap to see the new objects allocated on top of the previous run to see any extra objects still in memory at the end of each iteration.

Does that sound like an approach that makes sense?

If so, does anyone have any tips on how to properly diff the two heap dumps? Should I trim off part of the heap output and simply diff the rest? Is there already an option present to do this using other tools?

I’m happy to share the results. This approach is allowing me to take a popular iOS product and get its complete lack of memory management under (some) sort of control.

Thanks in advance.
Alex Zavatone.


-parallel-testing-worker-count

Alex Zavatone
 

If anyone has monkeyed around with iOS UITests and using the scheme TestAction option of "Execute in parallel on Simulator”, you might have noticed that we get 3 device clones to chew away at the tests all at once.

I see in xcodeBuild that we have the option of specifying the # of workers with -parallel-testing-worker-count.

Does anyone know if we can do that within Xcode? I’ve got a machine that can handle at least double the standard amount.

I looked in the scheme’s XML, but there is only a "YES" value for parallelizable but not an amount of parallel test devices.

<Testables>
<TestableReference
skipped = "NO"
parallelizable = "YES">

Thanks in advance.

Alex Zavatone


How to increase size of the minimap in XC11?

dhoerl
 

I watched the what's new WWDC video, and you can see at one point the minimap is increased in size by some key command. When that happens the Editor menu flashes. Try as I might, I can find no command to change the size anywhere within that menu. 

Does anyone know the magic incantation? 


Re: .xcconfig not being used for prefix header

John Brownie
 

Just to be clear, everything is working again. I eventually found where to adjust how the .xcconfig files are put in the chain, and it's in the Project view, in the Info tab, under Configurations. I don't know if something got changed behind my back, but setting the desired configuration at the project rather than target level fixed things. Of course, that begs the question why precompiling the prefix header doesn't use the target settings...

John
--
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland


Re: .xcconfig not being used for prefix header

Alex Zavatone
 

Oh, have you tried the Legacy Build System?

It is under your File menu in either Workspace Settings or Project Settings.

On Jul 22, 2019, at 1:05 AM, John Brownie <john_brownie@sil.org> wrote:

I have been working on changing a C/C++/Objective C app that uses the Nano library so that it uses the LLVM C++ Standard Library rather than the GNU version. After a fair bit of work in Xcode 9, I get it compiling there. However, I have a significant problem when I move to Xcode 10, in that the settings in the .xcconfig files (particularly the header search paths) are not being used when precompiling (or, it seems, compiling) the prefix header.

That is the basis of the problem, but there is another mystery which may be related. In the Nano project, the .xcconfig files are listed in the Levels view between the project and the target, whereas in the main project, they are between the macOS default and the project.

Since the problem manifests in Xcode 10.2.1 and not in Xcode 9.4, I assume that it is the "new build system" that is likely to be the culprit, but there doesn't seem to be enough documentation about it to be sure.

Anybody else have this sort of issue, or know of what I could tweak to get around this?

Thanks,
John
--
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland



Re: .xcconfig not being used for prefix header

Alex Zavatone
 

Check your build settings for the location of your precompiled header.

On Jul 22, 2019, at 1:05 AM, John Brownie <john_brownie@sil.org> wrote:

I have been working on changing a C/C++/Objective C app that uses the Nano library so that it uses the LLVM C++ Standard Library rather than the GNU version. After a fair bit of work in Xcode 9, I get it compiling there. However, I have a significant problem when I move to Xcode 10, in that the settings in the .xcconfig files (particularly the header search paths) are not being used when precompiling (or, it seems, compiling) the prefix header.

That is the basis of the problem, but there is another mystery which may be related. In the Nano project, the .xcconfig files are listed in the Levels view between the project and the target, whereas in the main project, they are between the macOS default and the project.

Since the problem manifests in Xcode 10.2.1 and not in Xcode 9.4, I assume that it is the "new build system" that is likely to be the culprit, but there doesn't seem to be enough documentation about it to be sure.

Anybody else have this sort of issue, or know of what I could tweak to get around this?

Thanks,
John
--
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland



Profiling UI Tests.

Alex Zavatone
 

I’m sure you all know that you can right click on a test in Xcode, select Profile and then run that test in Instruments.

Oddly, when I set my Test scheme to ask which test to launch or use NSZombies or Leaks, the only test that runs is Allocations, not the one I selected.

Any ideas? Are there any mutually exclusive scheme settings that would prevent this?

Thanks in advance.

Alex Zavatone


Re: .xcconfig not being used for prefix header

John Brownie
 

I found the issue in the end. For some reason, the configuration in one project was set at the project level, while it was at the target level in the other. When it is set at target level, definitions aren't applied to the precompiled header. Fixing that got me a clean compile at last.

John
--
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland


Re: .xcconfig not being used for prefix header

John Brownie
 

Header maps doesn't appear to be the issue. It is the fact that no header search paths are specified for the prefix header, except for one target. Looking at the two targets in the same project, both have the header file search path set correctly, and at the same level, but one ignores it for prefix, while the other doesn't.

Not having dealt with setting up .xcconfig files in many years (and this was already set up in the app template), I don't know how to ensure that they are invoked for any given target. Can someone point me to some useful documentation?

John

Sak Wathanasin wrote on 22/7/19 13:11:



On 22 Jul 2019, at 07:05, John Brownie <john_brownie@...> wrote:

I move to Xcode 10, in that the settings in the .xcconfig files (particularly the header search paths)

We use .xconfig files and have moved from XC9 through to XC11 and I haven't seen issues with settings in xcconfigs not being honoured. However, the big change between the old & new build systems, and the thing that is probably causing your problem, is that "header maps" are off by default with the new build system (there is a setting to revert to the old build system in the XC prefs).

"Header maps" was a feature where XC allowed you to refer to an include file by name whatever its actual path, so you could have

#include "foo.h"

even though its path may have been ..../my-subdir/..../foo.h and whether or not you had ..../my-subdir/..../ in your header search paths.

In the Xcode 10 rel notes, Apple says

• The legacy header map that was generated when the Always Search User Paths (ALWAYS_SEARCH_USER_PATHS) setting was YES is not supported by the new build system. Instead, set ALWAYS_SEARCH_USER_PATHS to NO and migrate to using modern header include syntax. Add any needed header files that are in the project repository to the Xcode project to ensure they are available for use in #include (via the project wide header map). Use quote-style include ("example.h") for project headers, and reserve angle-bracket include (<example.h>) for system headers.

I had to do a bunch of work to fix this in our projects. 

1) set USE_HEADERMAP = NO and  ALWAYS_SEARCH_USER_PATHS = NO in our xcconfig to set the global defaults
2) go through each project and made sure they weren't over-riding these settings
3) fix any "header file not found" errors by adding appr search paths in the projects' build settings

NB USE_HEADERMAP is "NO" by default with new build system; explicitly setting it to "NO' makes it behave the same way with the old build system. If you don't need to switch back to XC9, you can leave this out, I guess.

Also if you want to pass header paths defined in your xcconfig or global project settings down to individual target settings, you need to have

$(inherited)

as one of the "paths" in the settings.

You may have gotten away with it with the old build system since it would magically find the header file as long as it was in the source tree somewhere.

Hope this helps

Sak Wathanasin
Network Analysis Limited           http://www.network-analysis.ltd.uk


--
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland


Can't get IBOutlet to work for WKInterfaceGroup

Owen Hartnett
 

Hi all:

I have the following properties in my Watch App Extension:

@property (weak, nonatomic) IBOutlet WKInterfaceGroup *topGroup;
@property (weak, nonatomic) IBOutlet WKInterfaceGroup *bottomGroup;
@property (weak, nonatomic) IBOutlet WKInterfaceLabel *topScoreLabel;
@property (weak, nonatomic) IBOutlet WKInterfaceLabel *bottomScoreLabel;
@property (weak, nonatomic) IBOutlet WKInterfaceLabel *topLabel;
@property (weak, nonatomic) IBOutlet WKInterfaceLabel *bottomLabel;
@property (weak, nonatomic) IBOutlet WKInterfaceButton *gameScore;
@property (weak, nonatomic) IBOutlet WKInterfaceButton *topButton;
@property (weak, nonatomic) IBOutlet WKInterfaceButton *bottomButton;

The above are all connected to the proper places in the Watch App storyboard.  All of them, when the WKInterfaceController is loaded, are populated with values,
EXCEPT the two WKInterfaceGroup at the top. They have a null value.

I want to programmatically change the background color of the groups, which I can do in Interface Builder, but without Xcode returning a reference to the group, it’s impossible.

Here’s the object hierarchy in Interface Builder

Top Button
Group
Top Label
TopScoreLabel
Separator
Bottom Button
Group
Bottom Label
BottomScoreLabel

Could it be because the Group is a subview of the Button?  

Or should I report this as a bug?

-Owen


Re: .xcconfig not being used for prefix header

Sak Wathanasin
 



On 22 Jul 2019, at 07:05, John Brownie <john_brownie@...> wrote:

I move to Xcode 10, in that the settings in the .xcconfig files (particularly the header search paths)

We use .xconfig files and have moved from XC9 through to XC11 and I haven't seen issues with settings in xcconfigs not being honoured. However, the big change between the old & new build systems, and the thing that is probably causing your problem, is that "header maps" are off by default with the new build system (there is a setting to revert to the old build system in the XC prefs).

"Header maps" was a feature where XC allowed you to refer to an include file by name whatever its actual path, so you could have

#include "foo.h"

even though its path may have been ..../my-subdir/..../foo.h and whether or not you had ..../my-subdir/..../ in your header search paths.

In the Xcode 10 rel notes, Apple says

• The legacy header map that was generated when the Always Search User Paths (ALWAYS_SEARCH_USER_PATHS) setting was YES is not supported by the new build system. Instead, set ALWAYS_SEARCH_USER_PATHS to NO and migrate to using modern header include syntax. Add any needed header files that are in the project repository to the Xcode project to ensure they are available for use in #include (via the project wide header map). Use quote-style include ("example.h") for project headers, and reserve angle-bracket include (<example.h>) for system headers.

I had to do a bunch of work to fix this in our projects. 

1) set USE_HEADERMAP = NO and  ALWAYS_SEARCH_USER_PATHS = NO in our xcconfig to set the global defaults
2) go through each project and made sure they weren't over-riding these settings
3) fix any "header file not found" errors by adding appr search paths in the projects' build settings

NB USE_HEADERMAP is "NO" by default with new build system; explicitly setting it to "NO' makes it behave the same way with the old build system. If you don't need to switch back to XC9, you can leave this out, I guess.

Also if you want to pass header paths defined in your xcconfig or global project settings down to individual target settings, you need to have

$(inherited)

as one of the "paths" in the settings.

You may have gotten away with it with the old build system since it would magically find the header file as long as it was in the source tree somewhere.

Hope this helps

Sak Wathanasin
Network Analysis Limited           http://www.network-analysis.ltd.uk


.xcconfig not being used for prefix header

John Brownie
 

I have been working on changing a C/C++/Objective C app that uses the Nano library so that it uses the LLVM C++ Standard Library rather than the GNU version. After a fair bit of work in Xcode 9, I get it compiling there. However, I have a significant problem when I move to Xcode 10, in that the settings in the .xcconfig files (particularly the header search paths) are not being used when precompiling (or, it seems, compiling) the prefix header.

That is the basis of the problem, but there is another mystery which may be related. In the Nano project, the .xcconfig files are listed in the Levels view between the project and the target, whereas in the main project, they are between the macOS default and the project.

Since the problem manifests in Xcode 10.2.1 and not in Xcode 9.4, I assume that it is the "new build system" that is likely to be the culprit, but there doesn't seem to be enough documentation about it to be sure.

Anybody else have this sort of issue, or know of what I could tweak to get around this?

Thanks,
John
--
John Brownie
Mussau-Emira language, New Ireland Province, Papua New Guinea
Kouvola, Finland


Re: Undefined symbols for architecture arm64

Walter McCreary
 

Thanks, Alex.

My architectures build settings do match yours.

This is an old project, originating in 2009. There are 7 targets, and this behavior is common to at least 2 of them. At least one of them (the newest, from 2014) is okay. So, I’m assuming that the project build settings aren’t problematic.

Since my last email, I tried building the target in question after updating the .LinkFileList by hand, to include the new classes that the linker could not find previously. This worked, and the build for arm64 succeeded (though it did not touch or update the .LinkFileList).

I also tried a build without a .LinkFileList, to see if that would force its generation, but this failed, with the linker complaining that it couldn’t find the file. So, I’m guessing that the compiler must be responsible for generating that list for the linker. Do you know if that’s the case?

Anyway, I decided to just mv the project’s build directory out of the way, to force rebuilding the whole tree. This has tested ok for one of the targets in question - I have not yet tested any of the others.

-Walter

On Jul 19, 2019, at 21:30, Alex Zavatone via Groups.Io <zav=mac.com@groups.io> wrote:

Yeah, in build settings, what are your settings for Valid Architectures?

Just enter Architectures in the search field in Build Settings and that should help.

I’ve got these on one of my projects.

arm64 arm64e armv7 armv7s

Also, for Architectures, do you have this?
$(ARCHS_STANDARD)




On Jul 19, 2019, at 4:48 PM, Walter McCreary <walt@gigs.com> wrote:

Working on an iOS app, implemented in obj-C and C. I recently added a Cocoa touch class to the project, and the app builds and tests fine on iOS 12.2 simulators. However, when attempting to test on an actual device (iPhone X, and iPhone 7+, with iOS 12.3.1) the build fails when linking, with this error:
Undefined symbols for architecture arm64:
“_OBJ_CLASS_$_(the new class)”
ld: Symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1

I have tried adding 3 different classes to the project, each of which works fine on simulators, but fails as above when attempting to test with an actual arm64 device.

Looking at the build files, I find that the problem seems to be that the app’s .LinkFileList file is not being updated in the Objects-normal/arm64 directory (it is using one from February), whereas the x86_64 build (for the simulator) generates a new one at build time. Cleaning the Build Folder via Xcode has no effect.

So, I’m still mucking through this to find the actual root cause. I suppose I could just delete the old .LinkFileList in question, but that wouldn’t seem to solve the problem of why a new one is not being generated for each arm64 build. Are there any Clang settings that would help with this?

-Walter









Re: Undefined symbols for architecture arm64

Alex Zavatone
 

Yeah, in build settings, what are your settings for Valid Architectures?

Just enter Architectures in the search field in Build Settings and that should help.

I’ve got these on one of my projects.

arm64 arm64e armv7 armv7s

Also, for Architectures, do you have this?
$(ARCHS_STANDARD)

On Jul 19, 2019, at 4:48 PM, Walter McCreary <walt@gigs.com> wrote:

Working on an iOS app, implemented in obj-C and C. I recently added a Cocoa touch class to the project, and the app builds and tests fine on iOS 12.2 simulators. However, when attempting to test on an actual device (iPhone X, and iPhone 7+, with iOS 12.3.1) the build fails when linking, with this error:
Undefined symbols for architecture arm64:
“_OBJ_CLASS_$_(the new class)”
ld: Symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1

I have tried adding 3 different classes to the project, each of which works fine on simulators, but fails as above when attempting to test with an actual arm64 device.

Looking at the build files, I find that the problem seems to be that the app’s .LinkFileList file is not being updated in the Objects-normal/arm64 directory (it is using one from February), whereas the x86_64 build (for the simulator) generates a new one at build time. Cleaning the Build Folder via Xcode has no effect.

So, I’m still mucking through this to find the actual root cause. I suppose I could just delete the old .LinkFileList in question, but that wouldn’t seem to solve the problem of why a new one is not being generated for each arm64 build. Are there any Clang settings that would help with this?

-Walter






Undefined symbols for architecture arm64

Walter McCreary
 

Working on an iOS app, implemented in obj-C and C. I recently added a Cocoa touch class to the project, and the app builds and tests fine on iOS 12.2 simulators. However, when attempting to test on an actual device (iPhone X, and iPhone 7+, with iOS 12.3.1) the build fails when linking, with this error:
Undefined symbols for architecture arm64:
“_OBJ_CLASS_$_(the new class)”
ld: Symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1

I have tried adding 3 different classes to the project, each of which works fine on simulators, but fails as above when attempting to test with an actual arm64 device.

Looking at the build files, I find that the problem seems to be that the app’s .LinkFileList file is not being updated in the Objects-normal/arm64 directory (it is using one from February), whereas the x86_64 build (for the simulator) generates a new one at build time. Cleaning the Build Folder via Xcode has no effect.

So, I’m still mucking through this to find the actual root cause. I suppose I could just delete the old .LinkFileList in question, but that wouldn’t seem to solve the problem of why a new one is not being generated for each arm64 build. Are there any Clang settings that would help with this?

-Walter


Dynamic libraries in nonstandard locations - weak linking, or other solutions?

Jonathan Taylor
 

Hi all,

I’m having an involuntary adventure with the dynamic loader, as I attempt to link an ObjC code against anaconda python 3. (I worked out a solution for python 2.7 a while ago, but switching to python 3 has thrown up some more problems). The fundamental issue here is that there is a dynamic library “libpython3.5m.dylib” that my code must link against. That library lives in a nonstandard location and, depending on how anaconda was installed, it may be in a directory such as “/anaconda" or it may be in “~/anaconda” (which is even worse, as the path will vary from user to user). This nonstandard location is causing me a lot of grief!

At the moment there are several places where I have to customize the Xcode project file depending on the system that it’s sitting on:
- Path to the dylib as it appears in the file list and library search paths
- Header search paths
- Runpath search paths (so that the dylib location @rpath/libpython3.5m.dylib can be resolved at runtime)

The one that is really unfortunate is the runpath search path: if the built binary is copied to another machine (and anaconda lives in the user’s home folder) then the dylib will not be found on launch. Thus it’s not enough to customize the project file for the machine I am building on, it must be customized for the machine the binary will be run on.

I feel that there must be a solution to this - can anybody offer any advice about how to improve on the way I am handling this at the moment?

One thing I tried was to weak-link against the library, and load it myself from my code (at which point I can be a bit intelligent about figuring out where the dylib might actually be located on disk, on this particular machine). I don’t know if this is the best solution, but it seemed like a plausible one to me. This almost works. I can load the library using dlopen, and confirm that the symbol “Py_DecodeLocale” is present. However, when I actually call the function Py_DecodeLocale from my code, I get a runtime error “cannot resolve symbol _Py_DecodeLocale… because dependent dylib #2 could not be loaded”. I can fix this if I *do* specify a runpath search path in the project… but then I am back to hard-coding the location of the dylib at build time. Am I somehow missing something I need to do here? I would have expected that if I have loaded the library myself then I should be able to call the functions within it. Am I misunderstanding how weak linking is supposed to work?

[Note that the symbol reported as present by dlsym does NOT have a leading underscore, whereas the unresolvable symbol does. From my reading of the man pages, I think that is to be expected, but I’ll highlight it just in case it rings alarm bells for anyone…]


As you can see, I’m a bit lost with this - I am no expert on dynamic libraries, and am feeling my way around a bit in the hope of finding a “run-anywhere” solution that allows me to link to this dylib in a nonstandard location. Thanks for any suggestions.

Cheers
Jonny


Adding PDFKit palette to Xcode 10

Walter McCreary
 

I’m revising some iOS apps (for iOS 12.0) to use PDFView objects.  I have included the PDFKit framework, but the IB objects library does not contain  a PDFView.  PDFKit programming guide is out of date regarding adding the palette:

"A PDFView user interface element is available in Interface Builder, so you should use that wherever you want your application to display PDF content. Note that you need to install the PDF Kit palette in /Developer/Extras/Palettes/PDFKit.palette to make PDFViews available.
To add the PDFKit palette in Interface Builder, select the Palettes tab in the Preferences panel. Click the Add… button, navigate to the /Developer/Extras/Palettes folder, and select the PDFKit palette. Next, select the Customize Toolbar menu item in the Tools/Palettes menu and drag the PDFKit palette to the toolbar to make it visible. “
So, for Xcode 10, is there a way to add the PDFKit palette to the objects library?



promoting specific warnings to errors

yetanothermeagain
 

with obj-c / c / c++ compiler i was able to force specific warnings into errors on a "per warning" basis.

example, Xcode build console shows: "warning: unused variable 'i' [-Wunused-variable]"
i then take code in brackets and add it to "other warning" flags of Xcode:  -Werror=unused-variable
since then Xcode issues errors for this warning: "error: unused variable 'i' [-Werror,-Wunused-variable]"

note that i can do this per warning type, instead of a blank "-Werror" to force all warnings to be errors.

with swift compiler (and for some warnings in C/C++/Obj-C, presumably the new ones) i no longer see any code in brackets. is there a mechanism to achieve this behaviour, forcing specific warnings of my choice to be errors?

601 - 620 of 1433