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.

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.