Because the auto complete feature is triggered by pressing the return key, what happens is that even if I don’t want to use a snippet and just go to a new line, the snippet is triggered. For example, when I write an else block, I like to have the braces under the else keyword, unlike the snippet which puts them right after the keyword ( in the same line)

When I try to take it down one line (by pressing the enter key when the cursor is right before the opening brace), the else if snippet is triggered, when I didn't even need it.

I would like the snippets to be triggered only when I specifically tap them (or press return on a physical keyboard when the snippet is highlighted. This would greatly improve my coding speed

V 10.9.8

Can't open anything from the app.

File Explorer- open with - Textastic works fine.

Hi Alexander,

I would like to request an option to use the Tab key to cycle through code completion suggestions, especially when using Textastic with an external hardware keyboard on iPad.

I currently own an older iOS version of Textastic as well as the current macOS version, and I am considering purchasing the current iPad version as well. This particular feature would make the iPad version especially attractive to me as a serious LaTeX editing environment.

I use TeXShop extensively on macOS, and one of its features I find extremely efficient is its Tab-based command completion. I have also been experimenting with Textastic's custom CodeCompletion files on macOS, and Textastic already seems very close to being able to provide the same kind of workflow.

For example, suppose I define several completions related to a:

A
$a$
$A$

Ideally, I would like to be able to use the keyboard like this:

type: a

Tab    → first completion
Tab    → next completion
Tab    → next completion
Enter  → accept the currently selected completion

An alternative UI would also be perfectly fine:

a
Tab    → open the completion popup and select the first candidate
Tab    → select the next candidate
Tab    → select the next candidate
Enter  → accept

The important part for me is being able to cycle through the candidates by repeatedly pressing Tab, without having to move my hand to the Up/Down arrow keys.

For LaTeX and mathematical typing, this makes a surprisingly large difference. I use many short custom abbreviations, and keeping my hands in the normal typing position makes command completion much faster.

I understand that Textastic currently allows completion-list navigation using the arrow keys and Return. I would not want that behavior removed. Ideally, this could simply be an optional keyboard shortcut configuration.

For example, perhaps the existing completion navigation actions could be exposed under:

Settings → Keyboard Shortcuts

as commands such as:

Select Next Completion
Select Previous Completion
Accept Completion

Then a user could assign:

Tab        → Select Next Completion
Shift-Tab  → Select Previous Completion
Return     → Accept Completion

Ideally, Tab would have this special behavior only while the completion popup is active:

When no completion popup is active:
Tab → normal Tab / indentation / snippet behavior

When completion popup is active:
Tab → next completion
Shift-Tab → previous completion
Return → accept

That way, normal Textastic behavior would remain unchanged outside the completion list.

An even more TeXShop-like option would be to allow popup-free cycling, where each Tab immediately replaces the current text with the next completion:

a
Tab → A
Tab → $a$
Tab → $A$

with no popup required.

However, I think simply exposing “Select Next Completion” as a configurable keyboard command would already solve most of the problem and would be a very useful improvement.

I have already experimented quite a bit with Textastic's custom completion system, including CodeCompletion JSON files and snippets. The completion definitions themselves seem flexible enough; the missing piece is mainly the ability to control completion-list navigation from the Tab key.

Textastic already has many of the qualities I would want in an iPad LaTeX editor, and this would make the hardware-keyboard workflow much closer to what I currently enjoy in TeXShop on the Mac.

Thank you very much for considering it.

Opened a One-Drive text file and worked on it a few hours then closed it as I have previously, expecting file to auto-save. When i re-opened the file all of my work was gone. Has the auto-save functionality changed?

Device: iPad Pro 12.9-inch (5th generation)

OS Version: iPadOS 26.3 (23D127)

App Version: Textastic 10.9.2

Accessibility Feature: Voice Control (hands-free use)

Summary:

Voice Control fails to correctly deliver text input to Textastic's terminal view. This issue has persisted across two iPadOS updates, first observed on January 25, 2026, and remains unresolved as of iPadOS 26.3 (installed February 21, 2026) with Textastic 10.9.2.

Symptom:

Voice Control appears to be active and recognizing commands (as confirmed by testing in standard text fields like Notes), but no text is delivered to Textastic's terminal input field.

Root Cause Analysis:

The issue appears to stem from a conflict between the iPadOS Predictive Text / Composition Engine and how the terminal view handles input:

- When Voice Control processes speech, iPadOS inserts tentative (composition/draft) text into the input field.

- iPadOS then commits the final text, replacing the draft.

- The terminal view does not correctly handle this new two-phase input process, resulting in no visible text being delivered.

Steps to Reproduce:

1. Enable Voice Control via Settings > Accessibility > Voice Control.

2. Open Textastic and launch a terminal session (e.g., via SSH).

3. Use a voice command to dictate a terminal command.

4. Observe that text does not appear in the terminal input field despite Voice Control confirming recognition.

Expected Behavior:

Dictated text and Voice Control aliases should be inserted cleanly into the terminal input field, identical to how they work in Textastic's code editor and other standard text fields (e.g., Notes, Safari address bar).

Impact:

This bug renders Textastic's terminal view completely inaccessible for users who rely on Voice Control for hands-free operation.

Additional Notes:

- Standard text fields, including Textastic's own code editor, handle Voice Control input correctly, confirming the issue is specific to the terminal view's interaction with the iPadOS composition engine.

- The issue did not exist prior to the iPadOS update that introduced the behavior on or around January 25, 2026.

Opening a file from Files starts a new instance of Textastic. How can I open the file as a new tab of my existing instance instead?

On iPad OS 26.1, I usually leave my work files opened in textastic in multiple windows and it was about fine until recently where it’s common for the files to be closed / empty after a while.

It would be nice to have more persistence of opened files, I suspect iPad OS being more agressive on memory usage lately could explain that ? 

I work with a lot of opened apps and external screen / stage manager : I try to keep textastic windows and blinkshell in a stage, files are remote (through shellfish) and textastic up to date (10.8.3)

After adding and external source using a Samba share as defined in the File App some entry files in the left side column are missing.

That happen on iPad and not on iPhone (bot with Ios26]

The samba server is Debian based and seems correctly configured (on iPhone is working)

Do you have any suggestion?

Attached you will fine some screenshots

When downloading a directory, the app fails to fetch empty files, for example the __init__.py files in python packages. The error message is always that it hit maximum number of redirects, but I don’t think that’s the actual problem, I’ve never seen this error for anything else than empty files.

Great app otherwise!