Date   

Re: Problems registering AppID on the Apple Developer Site

Quincey Morris
 

On Aug 27, 2017, at 07:26 , Fritz Anderson <anderson.fritz@...> wrote:

You can't turn them off because there's nothing to turn off.

Also, the capabilities Dave mentioned *used to be* opt-in — for the App ID on the web site, either instead of or as well as in Xcode. Now they’re effectively always on (and/or managed within Xcode), but the web site seems to want to assert that they’re on for historical consistency (for people who are used to web site UI, I guess).


Re: Compiling Conditionally depending on OS

Jonathan Prescott
 

Also natively if you have OS X code grouped under TARGET_OS_OSX.
Jonathan

On Aug 27, 2017, at 7:46 AM, Dave <dave@...> wrote:

Ahhhh, well I suppose it *can* run on the Mac, under the simulator? e.g. TARGET_OS_SIMULATOR

On 26 Aug 2017, at 14:02, Dave <dave@...> wrote:

Great I’ve made a copy of them - thanks a million.

On 25 Aug 2017, at 18:28, Jens Alfke <jens@...> wrote:

TARGET_OS_MAC is incorrect — for some reason that evaluates to true on all Apple platforms. You want TARGET_OS_OSX instead. Here's the full list as documented in <TargetConditionals.h>, which is the header that defines these:

    TARGET_OS_* 
    These conditionals specify in which Operating System the generated code will
    run.  Indention is used to show which conditionals are evolutionary subclasses.  
    
    The MAC/WIN32/UNIX conditionals are mutually exclusive.
    The IOS/TV/WATCH conditionals are mutually exclusive.
    
    
        TARGET_OS_WIN32           - Generated code will run under 32-bit Windows
        TARGET_OS_UNIX            - Generated code will run under some Unix (not OSX) 
        TARGET_OS_MAC             - Generated code will run under Mac OS X variant
           TARGET_OS_OSX          - Generated code will run under OS X devices
           TARGET_OS_IPHONE          - Generated code for firmware, devices, or simulator
              TARGET_OS_IOS             - Generated code will run under iOS 
              TARGET_OS_TV              - Generated code will run under Apple TV OS
              TARGET_OS_WATCH           - Generated code will run under Apple Watch OS
              TARGET_OS_BRIDGE          - Generated code will run under Bridge devices
           TARGET_OS_SIMULATOR      - Generated code will run under a simulator
           TARGET_OS_EMBEDDED       - Generated code for firmware

Looking at this, I realize I have no idea what "Bridge devices" is. Anyone know?

—Jens




Re: Difference in View Identifiers between Mac and iOS?

Fritz Anderson
 

On 27 Aug 2017, at 6:44 AM, Dave <dave@...> wrote:

I’m moving some IB Views Across from iOS to Mac. By moving, I mean re-creating as you can’t copy+paste between iOS and Mac Storyboards.
Makes sense. NIBs contain freeze-dried instances of the objects themselves. UIView and NSView have no ancestors in common below NSObject.

In the IOS Storyboard view controller, I have some Views that need the Identifier set (e.g. [myView identifier]), when I look at he Class panel of these views, I see two identifier fields, one at the top in the “Identity” Panel with a “Restoration ID” field and one further down in the “Accessibility” Panel, “Identifier”.

I set the Accessibility Identifier in this case and it results in the ID appearing in the “identifier” property of the View.

On Mac there is an “Identity” Panel with an “Identifier” field and further down an “Accessibility Identifier” Panel with another “Identifier” field.

Which of these two fields should I be using to have it appear in the “identifier” property of the View? I have some common code that expects the view.identifier to be set correctly.

---

# What identifier?

Your mention of an `.identifier` property confuses me. Doc searches are always hit-or-miss, but it seems UIView has no property of exactly that name. I can’t see how your common code can expect a correct “identifier” when none exists.

Both have an `.accessibilityIdentifier`, but I believe it’s guaranteed unique only if fully-qualified by the IDs in its containment hierarchy, which may include indices. If your setup permits unique leaf identifiers this wouldn’t be a problem.

Both have view-restoration IDs, but with different names, `.identifier` for NSView, `.restorationIdentifier` for UIView.

---

# In Interface Builder

That’s the state of play when you get to the IB Identity inspector.

## UIView

Identity/Restoration ID, used for view restoration {→ UIView.restorationIdentifier).

Accessibility/Identifier, for access to the view in accessibility and automated testing (→ UIAccessibilityIdentification.accessibilityIdentifier).

## NSView

Identity/Identifier, used for window/view restoration (→ NSUserInterfaceItemIdentification.identifier).

Accessibility Identity/Identifier, again for accessibility (→ NSAccessibilityElementProtocol.accessibilityIdentifier).

## IB-only

IB has Document/Label everywhere so you can keep everything straight in the detail list and labels for constraints.

---

# Weird thing about accessibilityIdentifier

My archaeology says that accessibilityIdentifier was first exposed in iOS 8 retroactive to iOS 5. That may explain why some of the guides don’t illustrate the field. It’s apparently immemorial in OS X.


Re: Problems registering AppID on the Apple Developer Site

Fritz Anderson
 

Every where look there are glitches and bugs!

Amazing isn't it? You'd think that once they'd gotten past their first billion lines of code they'd have learned to straighten things out.

Those capabilities don't require permission sealed into the provisioning profile. Doesn't matter why they don't, it's how it works. You can't turn them off because there's nothing to turn off.

GameKit and IAP are cloud services. People notice they have to claim all the other cloud services; maybe they panicked over not being able to turn those on. Maybe Apple made an A/B test and found that "don't worry about those boxes" is easier to explain to the few who ask  than "we're sorry you're frantic after spending an entire workday looking for a way to turn them on."

    — F

On Aug 24, 2017, at 12:14 PM, Dave <dave@...> wrote:

Every where look there are glitches and bugs! What a total nightmare - thanks for letting me know, I thought I was going crazy!

Cheers
Dave


On 24 Aug 2017, at 18:17, Alex Zavatone <zav@...> wrote:


On Aug 24, 2017, at 10:59 AM, Dave <dave@...> wrote:

Hi,

I need to registers 6 Apps on the Apple Developer Site.

I’ve done 3 ok, there are LTWiPhoneAppX, LTWiPadAppX and LTWMacAppX these 3 all use GameKit and In-App Purchase and they are enabled ok.

The other 3, LTWiPhoneAppY, LTWiPadAppY, and LTWMacAppY do not use GameKit or Purchase, but when I come to create one of them, it won’t let me un-check these options on the Apple Developer Site. I created the App ID anyway and then tried to edit it, but again it won’t let me?

Why is this and how can I disable these options?

Yes, Apple won’t let you.  Yay, Apple!

As long as they are not enabled in the Capabilities part of your project settings, you should be OK.

I have felt your pain many many times, good sir.  You are not alone at being baffled as to why this is done.

GL and Godspeed, young Jedi.

Alex Zavatone







Re: Compiling Conditionally depending on OS

Dave
 

Ahhhh, well I suppose it *can* run on the Mac, under the simulator? e.g. TARGET_OS_SIMULATOR

On 26 Aug 2017, at 14:02, Dave <dave@...> wrote:

Great I’ve made a copy of them - thanks a million.

On 25 Aug 2017, at 18:28, Jens Alfke <jens@...> wrote:

TARGET_OS_MAC is incorrect — for some reason that evaluates to true on all Apple platforms. You want TARGET_OS_OSX instead. Here's the full list as documented in <TargetConditionals.h>, which is the header that defines these:

    TARGET_OS_* 
    These conditionals specify in which Operating System the generated code will
    run.  Indention is used to show which conditionals are evolutionary subclasses.  
    
    The MAC/WIN32/UNIX conditionals are mutually exclusive.
    The IOS/TV/WATCH conditionals are mutually exclusive.
    
    
        TARGET_OS_WIN32           - Generated code will run under 32-bit Windows
        TARGET_OS_UNIX            - Generated code will run under some Unix (not OSX) 
        TARGET_OS_MAC             - Generated code will run under Mac OS X variant
           TARGET_OS_OSX          - Generated code will run under OS X devices
           TARGET_OS_IPHONE          - Generated code for firmware, devices, or simulator
              TARGET_OS_IOS             - Generated code will run under iOS 
              TARGET_OS_TV              - Generated code will run under Apple TV OS
              TARGET_OS_WATCH           - Generated code will run under Apple Watch OS
              TARGET_OS_BRIDGE          - Generated code will run under Bridge devices
           TARGET_OS_SIMULATOR      - Generated code will run under a simulator
           TARGET_OS_EMBEDDED       - Generated code for firmware

Looking at this, I realize I have no idea what "Bridge devices" is. Anyone know?

—Jens



Difference in View Identifiers between Mac and iOS?

Dave
 

Hi,

I’m moving some IB Views Across from iOS to Mac. By moving, I mean re-creating as you can’t copy+paste between iOS and Mac Storyboards.

In the IOS Storyboard view controller, I have some Views that need the Identifier set (e.g. [myView identifier]), when I look at he Class panel of these views, I see two identifier fields, one at the top in the “Identity” Panel with a “Restoration ID” field and one further down in the “Accessibility” Panel, “Identifier”.

I set the Accessibility Identifier in this case and it results in the ID appearing in the “identifier” property of the View.

On Mac there is an “Identity” Panel with an “Identifier” field and further down an “Accessibility Identifier” Panel with another “Identifier” field.

Which of these two fields should I be using to have it appear in the “identifier” property of the View? I have some common code that expects the view.identifier to be set correctly.

Thanks a lot
All the Best
Dave


Re: Problems registering AppID on the Apple Developer Site

Dave
 

If I did that, I be spending 50%+ of my time filling in bug reports!

I can’t see this is an “edge” case, you create an AppID and set some capabilities, you create another one and it has the same capabilities as the first App and you can’t change them.

Cheers 
Dave

On 24 Aug 2017, at 19:36, Gary L. Wade <garywade@...> wrote:

Whenever you find what you believe to be a bug in Apple's software or web site, write a bug report about it. You might have experienced an edge case no one has yet tested.
--
Gary L. Wade
http://www.garywade.com/

On Aug 24, 2017, at 10:14 AM, Dave <dave@...> wrote:

Every where look there are glitches and bugs! What a total nightmare - thanks for letting me know, I thought I was going crazy!

Cheers
Dave


On 24 Aug 2017, at 18:17, Alex Zavatone <zav@...> wrote:


On Aug 24, 2017, at 10:59 AM, Dave <dave@...> wrote:

Hi,

I need to registers 6 Apps on the Apple Developer Site.

I’ve done 3 ok, there are LTWiPhoneAppX, LTWiPadAppX and LTWMacAppX these 3 all use GameKit and In-App Purchase and they are enabled ok.

The other 3, LTWiPhoneAppY, LTWiPadAppY, and LTWMacAppY do not use GameKit or Purchase, but when I come to create one of them, it won’t let me un-check these options on the Apple Developer Site. I created the App ID anyway and then tried to edit it, but again it won’t let me?

Why is this and how can I disable these options?

Yes, Apple won’t let you.  Yay, Apple!

As long as they are not enabled in the Capabilities part of your project settings, you should be OK.

I have felt your pain many many times, good sir.  You are not alone at being baffled as to why this is done.

GL and Godspeed, young Jedi.

Alex Zavatone






Re: Compiling Conditionally depending on OS

Dave
 

Great I’ve made a copy of them - thanks a million.

On 25 Aug 2017, at 18:28, Jens Alfke <jens@...> wrote:

TARGET_OS_MAC is incorrect — for some reason that evaluates to true on all Apple platforms. You want TARGET_OS_OSX instead. Here's the full list as documented in <TargetConditionals.h>, which is the header that defines these:

    TARGET_OS_* 
    These conditionals specify in which Operating System the generated code will
    run.  Indention is used to show which conditionals are evolutionary subclasses.  
    
    The MAC/WIN32/UNIX conditionals are mutually exclusive.
    The IOS/TV/WATCH conditionals are mutually exclusive.
    
    
        TARGET_OS_WIN32           - Generated code will run under 32-bit Windows
        TARGET_OS_UNIX            - Generated code will run under some Unix (not OSX) 
        TARGET_OS_MAC             - Generated code will run under Mac OS X variant
           TARGET_OS_OSX          - Generated code will run under OS X devices
           TARGET_OS_IPHONE          - Generated code for firmware, devices, or simulator
              TARGET_OS_IOS             - Generated code will run under iOS 
              TARGET_OS_TV              - Generated code will run under Apple TV OS
              TARGET_OS_WATCH           - Generated code will run under Apple Watch OS
              TARGET_OS_BRIDGE          - Generated code will run under Bridge devices
           TARGET_OS_SIMULATOR      - Generated code will run under a simulator
           TARGET_OS_EMBEDDED       - Generated code for firmware

Looking at this, I realize I have no idea what "Bridge devices" is. Anyone know?

—Jens


Re: How to store C Arrays as a Property or iVar?

 



On Aug 25, 2017, at 6:35 AM, Alex Zavatone <zav@...> wrote:

Is there a reason why he shouldn’t represent the values as NIntegers like I suggested before?  I didn’t see a response to my suggestion explaining why it’s not a good idea.


—Jens


Re: How to store C Arrays as a Property or iVar?

 



On Aug 24, 2017, at 10:37 PM, Jeff Laing <jefflaing@...> wrote:

My experience was that properties that are non-pointers work just fine, hence ints, reals, etc. but as soon as you start using pointers, the compiler starts squarking about ARC not liking those things.

NSData.bytes is a property of type "void*". And NSPointerFunctions even has a property whose type is a C function pointer:

@property (nullable) BOOL (*isEqualFunction)(const void *item1, const void*item2, NSUInteger (* _Nullable size)(const void *item));

ARC doesn't give a damn about C types, generally; it only pays attention to Obj-C references. The one C thing ARC will complain about is if you put an Obj-C reference type in a C struct, because there's no way to update the object's ref-count during the lifetime of the struct. (And that restriction goes away in C++ because ARC can add code to the constructor/destructor.)

I can see you are advocating a struct containing a fixed-size array and that may well work for the original poster - but if the array had been dynamically allocated, then I think it would have failed, the difference being that the compiler can believe it knows how to clone a fixed-size array (memcpy) whereas it can't be confident about indirect memory.

I've already pointed that out at least twice in this thread. That's just basic C; you can't write a plain C function that returns an array, for example.

—Jens


Re: Compiling Conditionally depending on OS

 

TARGET_OS_MAC is incorrect — for some reason that evaluates to true on all Apple platforms. You want TARGET_OS_OSX instead. Here's the full list as documented in <TargetConditionals.h>, which is the header that defines these:

    TARGET_OS_* 
    These conditionals specify in which Operating System the generated code will
    run.  Indention is used to show which conditionals are evolutionary subclasses.  
    
    The MAC/WIN32/UNIX conditionals are mutually exclusive.
    The IOS/TV/WATCH conditionals are mutually exclusive.
    
    
        TARGET_OS_WIN32           - Generated code will run under 32-bit Windows
        TARGET_OS_UNIX            - Generated code will run under some Unix (not OSX) 
        TARGET_OS_MAC             - Generated code will run under Mac OS X variant
           TARGET_OS_OSX          - Generated code will run under OS X devices
           TARGET_OS_IPHONE          - Generated code for firmware, devices, or simulator
              TARGET_OS_IOS             - Generated code will run under iOS 
              TARGET_OS_TV              - Generated code will run under Apple TV OS
              TARGET_OS_WATCH           - Generated code will run under Apple Watch OS
              TARGET_OS_BRIDGE          - Generated code will run under Bridge devices
           TARGET_OS_SIMULATOR      - Generated code will run under a simulator
           TARGET_OS_EMBEDDED       - Generated code for firmware

Looking at this, I realize I have no idea what "Bridge devices" is. Anyone know?

—Jens


Re: How to store C Arrays as a Property or iVar?

Gary L. Wade
 

If you want an actual property encapsulating your C-based array, you could keep it within an NSMutableData object since it’s just bytes.  I’m not sure if an NSData object would keep the actual data read-only (it’s certainly not growable), but it’s a VM-based optimization I’d expect to be a possible reason for not using NSData.

On Aug 25, 2017, at 6:54 AM, Dave <dave@...> wrote:

You could do that, but I’m doing millions of calculations on the elements of the Array, so it would be a lot slower and much more complex than needed……

On 25 Aug 2017, at 15:35, Alex Zavatone <zav@...> wrote:

Is there a reason why he shouldn’t represent the values as NIntegers like I suggested before?  I didn’t see a response to my suggestion explaining why it’s not a good idea.

[myArray addObject:[NSNumber numberWithInt:myValue]];
[myArray addObject:@myValue];
[myArray addObject:@(myValue)];









On Aug 25, 2017, at 12:37 AM, Jeff Laing <jefflaing@...> wrote:

No one said this was a property. It's just an instance variable.

Um, the headline says "How to store C Arrays as a Property ..." so at least one person (the original poster) has said this is about properties.

My experience was that properties that are non-pointers work just fine, hence ints, reals, etc. but as soon as you start using pointers, the compiler starts squarking about ARC not liking those things.

I can see you are advocating a struct containing a fixed-size array and that may well work for the original poster - but if the array had been dynamically allocated, then I think it would have failed, the difference being that the compiler can believe it knows how to clone a fixed-size array (memcpy) whereas it can't be confident about indirect memory.




Re: Compiling Conditionally depending on OS

Alex Zavatone
 

Dave, close to this topic, I make sure to add a build shell script to export the environment variables to my build process so that on a build, I can get an list of all the build variables for the project. This way, I can examine these and at least know what is already present that I can rely on or change.

On Aug 25, 2017, at 8:50 AM, Dave <dave@...> wrote:

Hi all,

How do I compile differently depending on the Platform I am compiling for?

I have an iOS project, but using the these macros:

#if TARGET_OS_IPHONE

// iOS code


#endif


#if TARGET_OS_MAC

// Mac code
#endif


Causes both iOS and Mac to be compiled? Are these the correct Macros to use? If not, what should I be using?

All the Best
Dave





Re: How to store C Arrays as a Property or iVar?

Dave
 

You could do that, but I’m doing millions of calculations on the elements of the Array, so it would be a lot slower and much more complex than needed……

On 25 Aug 2017, at 15:35, Alex Zavatone <zav@...> wrote:

Is there a reason why he shouldn’t represent the values as NIntegers like I suggested before?  I didn’t see a response to my suggestion explaining why it’s not a good idea.

[myArray addObject:[NSNumber numberWithInt:myValue]];
[myArray addObject:@myValue];
[myArray addObject:@(myValue)];









On Aug 25, 2017, at 12:37 AM, Jeff Laing <jefflaing@...> wrote:

No one said this was a property. It's just an instance variable.

Um, the headline says "How to store C Arrays as a Property ..." so at least one person (the original poster) has said this is about properties.

My experience was that properties that are non-pointers work just fine, hence ints, reals, etc. but as soon as you start using pointers, the compiler starts squarking about ARC not liking those things.

I can see you are advocating a struct containing a fixed-size array and that may well work for the original poster - but if the array had been dynamically allocated, then I think it would have failed, the difference being that the compiler can believe it knows how to clone a fixed-size array (memcpy) whereas it can't be confident about indirect memory.




Re: How to store C Arrays as a Property or iVar?

Dave
 

Well, you can’t use them as a property anyway, C Arrays *have* to be iVar’s, but I wrap a “Property Wrapper” around the iVars!

On 25 Aug 2017, at 07:37, Jeff Laing <jefflaing@...> wrote:

No one said this was a property. It's just an instance variable.

Um, the headline says "How to store C Arrays as a Property ..." so at least one person (the original poster) has said this is about properties.

My experience was that properties that are non-pointers work just fine, hence ints, reals, etc. but as soon as you start using pointers, the compiler starts squarking about ARC not liking those things.

I can see you are advocating a struct containing a fixed-size array and that may well work for the original poster - but if the array had been dynamically allocated, then I think it would have failed, the difference being that the compiler can believe it knows how to clone a fixed-size array (memcpy) whereas it can't be confident about indirect memory.



Compiling Conditionally depending on OS

Dave
 

Hi all,

How do I compile differently depending on the Platform I am compiling for?

I have an iOS project, but using the these macros:

#if TARGET_OS_IPHONE

// iOS code


#endif


#if TARGET_OS_MAC

// Mac code
#endif


Causes both iOS and Mac to be compiled? Are these the correct Macros to use? If not, what should I be using?

All the Best
Dave


Re: How to store C Arrays as a Property or iVar?

Alex Zavatone
 

Is there a reason why he shouldn’t represent the values as NIntegers like I suggested before?  I didn’t see a response to my suggestion explaining why it’s not a good idea.

[myArray addObject:[NSNumber numberWithInt:myValue]];
[myArray addObject:@myValue];
[myArray addObject:@(myValue)];









On Aug 25, 2017, at 12:37 AM, Jeff Laing <jefflaing@...> wrote:

No one said this was a property. It's just an instance variable.

Um, the headline says "How to store C Arrays as a Property ..." so at least one person (the original poster) has said this is about properties.

My experience was that properties that are non-pointers work just fine, hence ints, reals, etc. but as soon as you start using pointers, the compiler starts squarking about ARC not liking those things.

I can see you are advocating a struct containing a fixed-size array and that may well work for the original poster - but if the array had been dynamically allocated, then I think it would have failed, the difference being that the compiler can believe it knows how to clone a fixed-size array (memcpy) whereas it can't be confident about indirect memory.



Re: How to store C Arrays as a Property or iVar?

Jeff Laing
 

No one said this was a property. It's just an instance variable.

Um, the headline says "How to store C Arrays as a Property ..." so at least one person (the original poster) has said this is about properties.

My experience was that properties that are non-pointers work just fine, hence ints, reals, etc. but as soon as you start using pointers, the compiler starts squarking about ARC not liking those things.

I can see you are advocating a struct containing a fixed-size array and that may well work for the original poster - but if the array had been dynamically allocated, then I think it would have failed, the difference being that the compiler can believe it knows how to clone a fixed-size array (memcpy) whereas it can't be confident about indirect memory.


Re: How to store C Arrays as a Property or iVar?

 



On Aug 24, 2017, at 4:16 PM, Jeff Laing <jefflaing@...> wrote:

The reason I ask is that property values tend to need to support the NSObject protocol (ie, do the retain/release thing, whether manually or ARC) and I've always been given compilation failures whenever I try to start involving raw C memory management in that space.

No one said this was a property. It's just an instance variable.

Also, it's fine for properties to be C types — after all, there are plenty of integer or boolean properties, and UIKit and AppKit have properties whose types are structs like NSPoint and CGRect. I don't think a raw C array will work, since as mentioned before arrays aren't assignable in C, but a struct wrapping an array works fine.

—Jens


Re: How to store C Arrays as a Property or iVar?

Jeff Laing
 

Can I ask if this discussion is academic or you have already tried?

The reason I ask is that property values tend to need to support the NSObject protocol (ie, do the retain/release thing, whether manually or ARC) and I've always been given compilation failures whenever I try to start involving raw C memory management in that space.

1281 - 1300 of 1516