iOS
user interface
UI design
input elements
Apple design guidelines

iOS forces rounded corners and glare on inputs

Interview Questions practice on Codemia

Over 8,000 real interview questions from top companies, searchable by company and role.

Browse interview questions

Introduction

When HTML form inputs look rounded or glossy on iPhone and iPad, the source is usually Safari and WebKit applying native form-control styling. This is not iOS "ignoring" your CSS so much as the browser giving form elements a platform appearance unless you explicitly reset that appearance.

Why iOS Safari Styles Inputs Differently

Mobile Safari historically applies browser-specific rendering to controls such as input, button, and select. That can include rounded corners, gradients, shadows, and other native cues that do not match a custom design system.

If your CSS only sets a few properties, the browser may still keep pieces of the platform appearance.

Reset Native Appearance First

The normal fix is to remove the built-in appearance and then define your own styling completely.

css
1input,
2button,
3select,
4textarea {
5  -webkit-appearance: none;
6  appearance: none;
7  border-radius: 0;
8  background-image: none;
9  box-shadow: none;
10}

After that reset, add the styles you actually want:

css
1input {
2  border: 1px solid #c8c8c8;
3  border-radius: 6px;
4  padding: 12px;
5  background-color: #ffffff;
6  color: #222222;
7}

The important point is that you usually need both the reset and the replacement styles.

Watch Out for Special Input Types

Some input types carry stronger browser-specific behavior than plain text fields. Examples include:

  • 'search'
  • 'date'
  • 'time'
  • 'range'
  • 'file'

Those controls may keep special affordances or system-level widgets even after partial styling. For example, input[type="search"] often needs an explicit reset if you want it to behave like a plain text field.

css
input[type="search"] {
  -webkit-appearance: none;
}

If you are styling these controls heavily, test them individually on real iOS devices rather than assuming the desktop browser result will match.

Remove Residual Shadows and Highlights

Sometimes the rounded look disappears but a glossy or inset highlight remains. That is usually coming from box-shadow, background gradients, or browser-specific decoration.

css
1input {
2  -webkit-appearance: none;
3  appearance: none;
4  box-shadow: none;
5  background: #fff;
6  border: 1px solid #999;
7}

If an element still looks wrong, inspect it in Safari's web inspector and check for inherited styles from your own CSS framework as well as default WebKit behavior.

Web Views Behave Similarly

If the form is rendered inside a WKWebView, the same WebKit behavior applies because it is still browser-rendered HTML. That means CSS resets are still the right fix. UIKit styling APIs will not change the appearance of HTML form elements inside a web view.

This distinction matters because native UITextField styling and web input styling live in different layers of the stack.

Do Not Remove Usability With the Styling

It is easy to overcorrect and strip away all visible state cues. If you reset the input completely, you still need to provide:

  • visible focus state
  • adequate touch target size
  • sufficient contrast
  • disabled and error states

For example:

css
1input:focus {
2  outline: none;
3  border-color: #2d6cdf;
4  box-shadow: 0 0 0 3px rgba(45, 108, 223, 0.15);
5}

This keeps the control custom without making it harder to use.

Test on Real Devices

Many form-control differences show up only on actual iOS Safari or a real WKWebView. A desktop responsive emulator often misses the exact browser chrome and input styling quirks that matter here.

If the design is critical, test at least:

  • iPhone Safari
  • iPad Safari
  • in-app WKWebView if your app uses one

That catches style differences early instead of after release.

Common Pitfalls

The most common mistake is setting border or background styles without first resetting WebKit appearance. The browser then combines your custom styles with native styling and the result looks inconsistent.

Another issue is assuming one reset works for every input type. Search, date, and file inputs often need additional testing or separate styling decisions.

Developers also sometimes remove all native appearance but forget to replace focus and error states. The control may look cleaner but become harder to use.

Finally, do not confuse native UIKit controls with HTML inputs rendered in a browser or web view. They require different styling approaches.

Summary

  • Rounded corners and glossy input effects on iOS usually come from Safari or WebKit default form styling.
  • Reset -webkit-appearance and related visual properties before applying custom input styles.
  • Test special input types individually because they often keep extra browser-specific behavior.
  • Rebuild focus, error, and disabled states after removing native appearance.
  • Treat HTML inputs in Safari or WKWebView differently from native UIKit text fields.

Related reading
Free course
Beginner
7 lessons
2 hours
Tackling System Design Interview Problems

A short course that equips you with the skills to approach system design interviews methodically.

Start the free course
Track what you have practised

A free account saves your progress, solutions and study plan across every problem on Codemia.

Interview Questions practice on Codemia

Over 8,000 real interview questions from top companies, searchable by company and role.

Browse interview questions

All Rights Reserved.