I'm not seeing the 2nd part of the behaviour you describe. When I change it to macOS 13.0, or iOS 15.0, it stays there. To be honest, any .0 version is a bit risky. Apple isn't shy about releasing API changes in .x versions.

I think I'm making some progress. Here is what I've learned. Indentation cannot be disabled. End of story. So there's that. The most important setting is "Indent solo { by _ spaces". This has nothing to do with the "{" character. It affects every line. There is a concept of indentation context. This is the "indent width" setting. It is the number of spaces after an opening "{" to indent the next line of code. The "indent solo { by _ spaces" defines a negative indent from the indentation context. So, if I want to code Objective-C in this style: - (void) foo { handleValue(3); if(YES) { handleValue(4); } } I need an "Indent width" of 2 and an "indent solo { by _ spaces" of 2. They cancel each other out and my code lines up. The indentation context in Swift is more complicated. At the top level, it works like Objective-C. After the top level, Swift ignores the position of the opening brace. The context is defined in terms of the parent expression. if "indent width" and "indent solo {" are the same, then they cancel each other out and my subordinate block is indented at the same level as the parent, which is wrong in any language. In order to get my code to work (after the top level), I need to set "indent solo { by _ spaces" to zero. Luckily this field does accept zero. "Indent width" does not allow zero. What this means for people dealing with leftward indent problems, you may be able to fix the problem by setting "indent solo { by _ spaces" to zero, but only in Objective-C/C++. C++ seems to work like Swift's inner block logic. Set "indent solo { by _ spaces" to zero and it should fix it everywhere. But alas, poor me. I waited ten years to switch to Swift, and I didn't wait long enough to iron out the daily bugs.

Putting { on the same line as the method declaration doesn't change the behavior at all. It does for me. But my indentation is going the other way. I haven't been able to reproduce your unwanted indentation direction yet. The thing that bothers me is that there are something like 30 million registered developers, and some unknown number of download-only Xcode users. I have seen two people report unwarned right indentation and two people report unwanted left indentation. What are the other millions of people doing? Are our preferences just corrupted or something? And yet, people seem to be super excited about the new EditorConfig option. I had hoped it would allow users to control indentation settings. But no, it does virtually nothing. Instead of choosing spaces or tabs in Xcode settings, we can create a new file, add it to an Xcode project, and that will specify whether we want to use spaces or tabs. Hallelujah! That's literally all it does. In my case, I've turned off all indentation options. But this is the one indentation that I can't disable. Since you are going the other way, try turning off your indentation settings.

I get that sdk code is our responsibility, but the fact is, people dont know that the app shares the same sandbox as the sdk and so they might not know to consider that before adopting an sdk. or consider that when they make new files in the filesystem. I think you're greatly over-estimating the amount of research that the average developer does before incorporating 3rd party frameworks. That's why Apple added the requirement for Privacy Manifests when using certain frameworks. You're certainly correct that this could be an issue if the developer didn't understand. But there's no coding or knowledge test required before being allowed to distribute apps.

Here is what Apple said in reply to my bug report in June. Please know that there is a setting that controls this (which should be off by default). In Xcode > Settings > Text Editing > Editing, it’s called “Automatically reformat when completing code”. I don't know what "controls this" means. Does "on" mean add unwanted indentation and "off" mean do not add unwanted indentation? But regardless, I filed another report regarding this setting having no effect. Apple's reply: It only reformats code that’s wider than the specified column, and only if the code is made up of nested expressions (function calls, etc), that can be wrapped to new lines. In any case, my code never extends to the "Reformat code at column" location, as shown in my screen recordings. Every line jumps around. Mine go in the opposite direction from yours. But it's never where I want it. Obviously I don't understand the logic that Apple's using for these indentations. But it seems clear that there is only one coding style that Apple now allows - this one: - (void) applicationDidFinishLaunching: (NSNotification *) aNotification { int value = 1; } The key is having that opening brace on the previous line. Nothing else is allowed. I still don't understand why your indentation is going backwards from mine. But thanks for posting your settings screenshots. I'll try to reproduce this later on Sequoia. I'm still using Ventura for production work. 😄

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.