Skip to content

Fix horizontal scrolling on mobile #63

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
leogdion merged 2 commits into from
Apr 29, 2026
Merged

Fix horizontal scrolling on mobile #63

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
62d51da
Fix horizontal scrolling on mobile
leogdion Apr 29, 2026
20a0aa5
Making a few edits to the tuist post
leogdion Apr 29, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 7 additions & 4 deletions Content/tutorials/tuist-xcode-project-setup.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,11 +12,11 @@ subscriptionCTA: Want to stay up-to-date with the latest Swift tooling and CI/CD

When creating an app, let’s think about what we need to get started. The Xcode project is the backbone of your application — it contains metadata like bundle identifiers and permission text, along with build configuration for your targets, which can include the app itself, frameworks, and app extensions.

The Xcode project uses a _proprietary format_ that is notoriously difficult to work with, especially when dealing with merge conflicts in version control.
The Xcode project uses a _proprietary format_ that is notoriously difficult to work with, especially when dealing with merge conflicts in version control. In the ancient days, it was Storyboards and Xcode projects which were the biggest culprits of merge conflict hell. Coding your UI in UIKit and then SwiftUI eleviated the Storyboard issue but Xcode projects still remain.

This is where a tool which creates the Xcode project is most helpful. There’s 2 leading tools which I’d recommend: Xcodegen or Tuist. Xcodegen is great if you have a fairly simple app or minimal team structure. Xcodegen uses YAML for its specification structure — if you prefer a simpler static config format, it’s the right choice. For a broader look at both tools, see [How to automate iOS development](/articles/ios-automation/).
This is where a tool which creates the Xcode project is most helpful. There’s 2 leading tools which I’d recommend: Xcodegen or Tuist. [Xcodegen](https://github.com/yonaskolb/xcodegen) is great if you have a fairly simple app or minimal team structure. Xcodegen uses YAML for its specification structure — if you prefer a simpler static config format, it’s the right choice. For a broader look at both tools, see [How to automate iOS development](/articles/ios-automation/).

Tuist is what I’d recommend in most any other case. Tuist uses Swift for its manifest files, which is a deliberate design choice — it gives you type-checking and the full power of the language for complex configurations. Tuist has a very robust community and support as well. In the end I’d highly recommend **not** committing Xcode projects to your code repository.
[Tuist](https://tuist.dev) is what I’d recommend in most any other case. Tuist uses Swift for its manifest files, which is a deliberate design choice — it gives you type-checking and the full power of the language for complex configurations. Tuist has a very robust community and support as well. In the end I’d highly recommend **not** committing Xcode projects to your code repository.
Comment on lines +15 to +19
Copy link
Copy Markdown

@coderabbitai coderabbitai Bot Apr 29, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Polish intro copy for clarity and correctness.

There are a few user-facing text issues in this edited block (eleviated, “There’s 2”, and “most any”) that read as errors in published content.

Suggested copy edit 
-The Xcode project uses a _proprietary format_ that is notoriously difficult to work with, especially when dealing with merge conflicts in version control. In the ancient days, it was Storyboards and Xcode projects which were the biggest culprits of merge conflict hell. Coding your UI in UIKit and then SwiftUI eleviated the Storyboard issue but Xcode projects still remain.
+The Xcode project uses a _proprietary format_ that is notoriously difficult to work with, especially when dealing with merge conflicts in version control. In the past, Storyboards and Xcode projects were the biggest culprits of merge-conflict pain. Coding UI in UIKit and later SwiftUI alleviated many Storyboard issues, but Xcode projects still remain.

-This is where a tool which creates the Xcode project is most helpful. There’s 2 leading tools which I’d recommend: Xcodegen or Tuist. [Xcodegen](https://github.com/yonaskolb/xcodegen) is great if you have a fairly simple app or minimal team structure. Xcodegen uses YAML for its specification structure — if you prefer a simpler static config format, it’s the right choice. For a broader look at both tools, see [How to automate iOS development](/articles/ios-automation/). 
+This is where a tool that generates the Xcode project is most helpful. There are two leading tools I recommend: Xcodegen and Tuist. [Xcodegen](https://github.com/yonaskolb/xcodegen) is great for a fairly simple app or a smaller team structure. Xcodegen uses YAML for its specification format — if you prefer a simpler static config, it’s the right choice. For a broader look at both tools, see [How to automate iOS development](/articles/ios-automation/).

-[Tuist](https://tuist.dev) is what I’d recommend in most any other case. Tuist uses Swift for its manifest files, which is a deliberate design choice — it gives you type-checking and the full power of the language for complex configurations. Tuist has a very robust community and support as well. In the end I’d highly recommend **not** committing Xcode projects to your code repository.
+[Tuist](https://tuist.dev) is what I’d recommend in almost any other case. It uses Swift for manifest files, which is a deliberate design choice — you get type-checking and the full power of the language for complex configurations. It also has a robust community and strong support. In the end, I highly recommend **not** committing Xcode projects to your repository.
🧰 Tools
🪛 LanguageTool

[grammar] ~15-~15: Ensure spelling is correct
Context: ...oding your UI in UIKit and then SwiftUI eleviated the Storyboard issue but Xcode projects...

(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)

[style] ~19-~19: Avoid the colloquial phrase ‘most any’ in formal writing. Use “almost any” instead.
Context: ...s://tuist.dev) is what I’d recommend in most any other case. Tuist uses Swift for its ma...

(MOST_EVERYONE)

[style] ~19-~19: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...he language for complex configurations. Tuist has a very robust community and support...

(ENGLISH_WORD_REPEAT_BEGINNING_RULE)

🤖 Prompt for AI Agents 
Verify each finding against the current code and only fix it if needed.

In `@Content/tutorials/tuist-xcode-project-setup.md` around lines 15 - 19, Fix the
three user-facing copy issues in the paragraph: replace "eleviated" with
"alleviated", change "There’s 2 leading tools" to "There are two leading tools",
and change "most any case" to "most cases" (or "most other cases"); ensure the
surrounding sentences read smoothly and keep emphasis on not committing Xcode
projects to the repo. Update the strings in the
Content/tutorials/tuist-xcode-project-setup.md block containing those phrases.


# Using Tuist

Expand Down Expand Up @@ -322,7 +322,8 @@ So in our case, our `infoPlist` would look like:

This will make it much easier to increment the build number or change the marketing version.

### Ignoring Our Project
---


This is what we should have for our end result:

Expand Down Expand Up @@ -366,6 +367,8 @@ let project = Project(

This will give us a fully working Xcode project but before we commit this to our repository, **we need to make sure we aren't committing our project and workspace.**

### Ignoring Our Project

If you don't already have a .gitignore file, [toptal has a great resource for creating one](https://www.toptal.com/developers/gitignore). I even have a url I download from everytime:

```
Expand Down
4 changes: 2 additions & 2 deletions Package.resolved
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

11 changes: 8 additions & 3 deletions Styling/styles/styles.css
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,6 +5,10 @@
@tailwind components;
@tailwind utilities;

html {
overflow-x: hidden;
}

._button_normal {
@apply text-gray-800 bg-bellow-500 p-2 rounded-lg no-underline;
&:hover {
Expand Down Expand Up @@ -73,7 +77,7 @@ body.more-active {
@apply relative z-0;
}
& > header > nav {
@apply bg-white w-screen absolute top-0 left-0 right-0 p-2 flex flex-col items-stretch bg-opacity-90 z-50 duration-1000;
@apply bg-white absolute top-0 left-0 right-0 p-2 flex flex-col items-stretch bg-opacity-90 z-50 duration-1000;
transition-property: top;
@apply shadow-lg;
& > ol.more {
Expand Down Expand Up @@ -1276,7 +1280,7 @@ body.articles, body.tutorials {
img {
@apply w-full mt-4 h-40 object-cover sm:h-48 md:h-64 lg:h-80 xl:h-96;
&.full-size {
@apply w-auto h-auto;
@apply w-auto h-auto max-w-full;
@apply xl:max-w-2xl xl:mx-auto;
}
&.contained{
Expand Down Expand Up @@ -1312,7 +1316,8 @@ body.articles, body.tutorials {
@apply my-4;
}
pre code {
@apply whitespace-pre-wrap text-xs font-extralight p-4 bg-gray-900 text-white block my-4 lg:text-base lg:p-8;
@apply whitespace-pre-wrap text-xs font-extralight p-4 bg-gray-900 text-white block my-4 lg:text-base lg:p-8;
overflow-x: auto;
Comment on lines +1319 to +1320
Copy link
Copy Markdown

@coderabbitai coderabbitai Bot Apr 29, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Fix stylelint failure on declaration spacing.

Line 1320 needs an empty line before overflow-x: auto; to satisfy declaration-empty-line-before.

Suggested fix 
       pre code {
         `@apply` whitespace-pre-wrap text-xs font-extralight p-4 bg-gray-900 text-white block my-4 lg:text-base lg:p-8;
+
         overflow-x: auto;
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
@apply whitespace-pre-wrap text-xs font-extralight p-4 bg-gray-900 text-white block my-4 lg:text-base lg:p-8;
overflow-x: auto;
`@apply` whitespace-pre-wrap text-xs font-extralight p-4 bg-gray-900 text-white block my-4 lg:text-base lg:p-8;
overflow-x: auto;
🧰 Tools
🪛 Stylelint (17.9.0)

[error] 1320-1320: Expected empty line before declaration (declaration-empty-line-before)

(declaration-empty-line-before)

🤖 Prompt for AI Agents 
Verify each finding against the current code and only fix it if needed.

In `@Styling/styles/styles.css` around lines 1319 - 1320, The stylelint failure is
caused by missing empty line before the declaration `overflow-x: auto;`; edit
the CSS rule that contains the `@apply whitespace-pre-wrap ...` declaration and
insert a single blank line immediately before the `overflow-x: auto;` line so
there is an empty line between the `@apply ...;` statement and the `overflow-x`
declaration to satisfy the `declaration-empty-line-before` rule.


.keyword {
@apply font-bold;
Expand Down
Loading