What do you mean by "default Hello World code"? When I create a new project using the default iOS App template, the minimum deployment target is iOS 18.2. I can change that all the way back to iOS 15 and the app still works fine. I tried both Swift and SwiftUI templates. In the past, I have seen Xcode's default templates be unusable on older deployment targets. Typical solutions are: Use an older project as a template Remove the offending code Install an older Xcode on an older computer or VM.

I would still like to know why Xcode no longer allows for debugging as it did prior to the last update. I don't know exactly. I know that Apple made major changes to the Console in Xcode 15. It doesn't surprise me at all that ncurses wouldn't work in the Console. I'm surprised it was working before.

Written by berilbayram in 772649021 How do you get those fancy quote blocks? I can't even get blank lines to work properly when I'm trying to quote multiple blocks.

I mentioned using the Terminal option in my original post. Sorry. I missed that. I took another look at it anyway. I figured it out. You definitely have to use the Terminal option. But additionally, in "Edit Scheme" > Run, go to the "Info" tab. Change "Launch" to " wait for executable to be launched". Click the "Run" button. Xcode will be in "Waiting to attach" mode. Then, in a Terminal window, manually run the executable using a path to the debug executable in DerivedData. In my case, that was: "/Users//Library/Developer/Xcode/DerivedData/cursestest-ctczepmnawedaxejmabotxmbzwov/Build/Products/Debug/cursestest". Make sure you have a break point already inserted where you want to start debugging. Once you run the executable manually, Xcode should detect it and automatically start debugging. It will stop at your breakpoint and you're ready to debug!

The Xcode debugger console is a very funky environment. I'm more surprised that it was working before than that it isn't working now. There is a way to get closer. In Xcode, go to Edit Scheme... Click the Options tab Scroll to the bottom and change Console to "Terminal" This will launch your app in a real Terminal window. You can debug in Xcode and see the output in a separate Terminal window, at least in theory. I tried it with your code and I couldn't get it to work. It works, but it doesn't display any output. Perhaps you can hack around on environment variables or something? Or perhaps there are other ncurses functions or settings you can try that will make it work. And there might be some way to dig into the "darwin-debug" executable that is running your executable.

I’m developing a sandboxed macOS app using Qt, which will be distributed via the Mac App Store. The app: Monitors the clipboard to store copied items. Overrides the paste function of the operating system via keyboard shortcuts. Modifies clipboard content, replacing what the user pastes with stored data. Have you tested this? Your first statement suggests this is something in progress, for future release. Your other statements suggest these features are already functional. #1 and #3 are doable, albeit tricky trying to do both at the same time. I would be very surprised if you could do #2 from an app. That's something the user would have to do. Can a sandboxed app continuously read and modify clipboard content? Sure What entitlements are required? None What permissions should I request from the user to ensure that my app works? That's going to be tricky. It sounds like App Review might not like this. In my experience, they seem to want an app to be fully functional without asking the user for anything extra. By that I mean they consider the full functionality of an app to be that which it can do without asking for anything extra. They may not let you claim any of that extra stuff in your app's description or screenshots. Of course, I'm making assumptions and gross generalizations here. I'm not App Review and I can't speak for them. All I can do is relate my own experience, as well as imagine what I would do if I were working for App Review. I can tell you that App Review doesn't pre-authorize anything. You have to develop it all, submit, and hope they approve. You also have to think maliciously. Imagine yourself as a developer doing evil things. Could your app facilitate that activity? In other words, look at your app objectively, from App Review's perspective. Is this an app that would bring value to our customers? (i.e. They are Apple's customers, not yours.) And I think you should also think of the value the app would bring to you as the developer. I used to have a similar app in the Mac App Store. I pulled it years ago and nobody misses it. There are lots and lots of other clipboard apps. What's that Qt code base going to do for you in the future? Compare all of that to a more straightforward app, that doesn't deeply involve itself in any system services, written in SwiftUI, for iOS and all other Apple platforms. Just something to consider.

I don't understand your question. When you say "SDK", are you referring to a bundled framework or dylib? I don't understand why any warning would be necessary. Also, you mention the "Documents" directory but then your code mentions the caches directory. Which are you asking about? Or perhaps you are thinking of a "Documents" directory outside of the app's sandbox? That's only on macOS and only for non-sandboxed apps. Sandboxed apps live in their own little world - the sandbox.

It's not in App Store Connect. It's in right where you said: Account > Membership details The big blue iOS-style switch control

I want to use realtime data from the trains and buses in Sweden. As I understand it I should use GTFS data which come in Protobuf format. I think I must convert the Protobuf-data to Swift code. Not sure if this involves json. Protobuf is a data transfer protocol invented by Google to support its online mapping services. It's now the de-facto standard for transferring vector data tiles. It's likely that anyone using public transit data is going to want to map it. So Protobuf is a good choice because anyone doing mapping is probably already familiar with the protocol. Protobuf has nothing to do with JSON. And you don't convert it to Swift. It's a long story. I tried to use this page: I really appreciate it when people include the URL to a tutorial they are trying to use. Thanks! Unfortunately, that tutorial is over 6 years old now. While the general concepts haven't changed, it's unlikely that any of those command will work on modern systems. Specifically, it is checking out an ancient version (1.1.1) of Swift-protobuf and then trying to compile it with a modern Swift toolchain, using obsolete build settings. If you omit the "checkout tags" part, and drop the static build, then it will work fine. However, there are still some significant problems you'll encounter. The Protobuf protocol itself is quite simple. Google's implementation of it is, like many such Google implementations, crazy, over-top-complicated. And Apple's Swift-protobuf project builds on top of that. Google's own Protobuf implementation is on the list requiring a Privacy manifest. I don't know what's going on in there. I can't provide any assistance with Google's or Apple's implementation. In theory, it's easy to incorporate a Swift package into an Xcode project. I don't know if that would apply in this case. And that tutorial pre-dates Swift packages anyway. I would recommend you find a different Protobuf implementation. You might even need to look for one based in C or Objective-C. This kind of data serialization protocol isn't very friendly with Swift's static typing. That's one reason why this is all so complicated. To put it into perspective, I wrote my own Protobuf decoding logic with 300 lines of Objective-C code - including comments!

Did you ever get to the bottom of this? I thought cleaning the build folder would fix it, but it doesn't. My code runs nearly 10x faster under the profiler than in the Release build. The OP posted that question over 3 years ago. They haven't even logged onto the site in a year. Are you also trying to hack up your own release build on the command line? I'm sure you could do that, if you took the time to learn all the details of how Xcode builds an app. But it's much easier to just do an archive build and let Xcode handle it for you.

It's best to reply as a new reply. The "comment" functionality only serves to hide activity. I'm not familiar with the Network framework. They don't seem to be all that sensitive. In every reference I can find, people are just using ".main" or ".global()". When Apple engineers respond, they don't seem to be complaining about that. So perhaps you're just thinking too hard. That being said, many apps are little more than demo apps. And I have seen Apple engineers go out of their way to recommend against ".global()" in other places. Many years ago, I tried to write some real-world networking apps and ran into many of the same kinds of detailed questions that you are asking. I was trying to use GCD networking directly, before the Network framework existed. My solution was to switch to a simpler, more well-defined, and proven API - BSD sockets. You do have that same option too. There is always a risk when committing to a new API that depends on some other technology that later falls out of favour and/or use. I think your other question is much more straightforward and specific. Hopefully you'll get a good answer there.

Why do you care? And why are you avoiding the elephant in the room - Swift Concurrency? While GCD isn't deprecated, it does appear to be disavowed. Given that documentation was never its strong suit, and no one ever really knew how to use it, it seems like it would be risky to rely on any of those answers even if you could get them. If Apple breaks and/or changes Swift Concurrency, they'll have to document it. Or, if nothing else, people will figure it out and complain about it online. Either way, with a large user base, the word will get out. But if Apple changes anything at the GCD layer, perhaps to support those upcoming changes to Swift Concurrency, anyone relying on low-level GCD behaviour is going to be in a pickle and no one will be able to help.

Posting your feedback ID in these discussion forum questions does seem to result in more attention from people who can affect change. I would like to know what happens in your case if you turn off all indentation. I would also like to know what your Xcode editing and indentation settings are. You are one of the only people I've seen who has mentioned this problem. Since I can't reproduce your specific experience, if I could reproduce it, I might be able to tell you what causes it. And maybe I could figure out a way to fix my version of the indentation problem.

Xcode 16 unindents lines if I choose a code-completion and I cannot find a way to stop this - does anybody know how to stop it? Here's a link to a gif demonstrating this problem - it's incredibly frustrating. That's strange. I see the exact opposite. I have all indentation turned off, yet any use of code completion adds an unwanted indent. I filed two feedbacks about this in June. Both were closed with nonsensical replies. FB13893391 FB14102219 But I've definitely never seen it unindent the way you describe. But I'm mainly using Swift these days. I just tried with a C++ test project and I can't reproduce what you are seeing when I have all indentation settings turned off. I also tried turning on various settings to trigger what you are seeing, but I couldn't do it. File a feedback. Maybe you'll get better results than I did. Then turn off all indentation. At least for C++, that seems to work. I guess I should have stuck with C++ instead of switching to Swift.

The sidebar is the result of using the Source List style for your navigation table view. You have to add the sidebar toggle button yourself. Set the "isNavigational" property to true so that it appears in a navigation location in the titlebar. I think there is some sort of "toggleSidebar" operation. There is a menu item for it. But the built-in operation isn't animated. For an animated collapse, you'll need to set the "isCollapsed" property of first NSSplitViewItem, using the "animator()" proxy, of course. Rest assured, it is much more complicated than it sounds. There's a reason why SwiftUI is so popular. If you hit the wall on what SwiftUI offers, you have to make some hard choices.