Hi, After spending two months trying to launch this app I decided to start from scratch, and regenerate everything from code signing requests, certs, apps, appIDs, App Store entries, EVERYTHING, and at the end of all of it, I get exactly the same problem I've had for months: "Invalid Provisioning Profile. The provisioning profile included in the bundle com.chiltonwebb.secretprojectname [com.chiltonwebb.secretprojectname.pkg/Payload/secretprojectname.app] is invalid. [Invalid 'com.apple.application-identifier' entitlement value.] For more information, visit the macOS Developer Portal. (ID: 723cede2-3c9f-4069-b4fa-581ebd3468b9)" I'm tired of guessing. I've tried everything I can find in these forums. What is the official way to diagnose this problem? -Chilton

Hi, I have a developer tool that often needs access to files outside of the file the user has selected. For example, they can easily select a file that contains a reference to an include file NOT in the current folder or a descendent. But I still need access to that file. How do I handle this, on the latest version of MacOS? Right now it just fails to give me access to the file, making it look like our Mac version is WAY BEHIND the Windows version. Oh and this needs to be in the App Store eventually, but right now I need it to be available outside of it, so I have to use my Developer ID and notarized. I think I've got all of that nailed down, but I'm still having file permission issues. My entitlements currently (which doesn't work): com.apple.security.cs.disable-library-validation com.apple.security.cs.disable-executable-page-protection com.apple.security.app-sandbox com.apple.security.files.user-selected.read-write Thank you, -Chilton

I have an app that needs to read a file the user selects from an Open dialog. Right now it works fine on my machine (of course), but doesn't let my app access the file on other systems. I code signed it using my Apple Developer ID. I have notarized it. I have checked it all with the notaryTool and it shows NO ERRORS and as far as I can tell, no warnings either. Here's the entitlements: com.apple.security.cs.disable-library-validation com.apple.security.cs.disable-executable-page-protection com.apple.security.app-sandbox com.apple.security.files.user-selected.read-write What could I be doing wrong? Thank you, -Chilton

Hi,I've been a Mac developer since the late 80's. I've had my name on somewhere around 500 commercial products spanning every part of Mac and iOS software. I ran the largest Mac source code repository on the planet (4Gb of raw source code on DevHQ) until Dr. Dobb's Journal took it over. My point is that I've been here for a long time now.This morning I spent *FOUR F*CKING HOURS* trying to make a @#$# button correctly span the width of a view, without screwing up everything else I delicately placed in the view.This is *PAINFUL*.Unity3D, by comparison, has an almost effortless UI system. I mocked up *THIS* UI in Unity so I could test it, before trying to make it work in Xcode. Think about that.This is shameful. Look, Interface Builder has never been particularly *great* at UI design, but it wasn't this bad.I know it's not just me. Every client I've worked with in the last five years has had problems navigating Interface Builder. Every time there's an update, I pore over the documentation and try to figure out what *BROKE* and what new, stupider, way of handling UI issues you've invented. I do this because my clients call within days of each major Xcode update to ask how to do something they used to do.And if I'm having problems with this, I guarantee this is a stumbling block for new users.Here's a simple solution: The last time I was at WWDC, you had a team of UI specialists I could go sit with who would help me find roadblocks my users might encounter in my UI. Please, Apple, have your UI specialists spend some quality time on Interface Builder.Have some **** pride, people. Now I'm going to go randomly click on crap and see if I stumble over something that works better than following the directions. -Chilton

Hi, I have old code based on Apple's sample code (Sketch, I think) that uses the NSData.description method to return a hex string that can be saved in PLIST format, in its document data. My app then reads that format for the document and recreates objects as needed. I don't see any documentation for NSData.description changes, despite that this has apparently broken a number of apps that rely on it. This was Apple sample code, and was an Apple sanctioned method of dealing with this type of data. Is there a replacement for it? If not, should I move away from NSData to store information, if it cannot save data in a human readable format anymore? Thank you,Chilton