Absolutely, there are several fantastic apps out there that let you create custom backgrounds with text! One of my personal favorites is Canva. It's incredibly user-friendly and packed with templates that make designing a breeze.

You can start from scratch or use one of their many pre-designed backgrounds. Adding text is super simple – you just drag and drop. Plus, Canva offers a wide array of fonts, so you can really get creative and find the perfect style to match your background.

Here is example designs -

Amongst many others, those are some of the more important ones:

• Apple has very strict UI guide lines you should follow, otherwise you risk that your app gets denied. See more in their HIG (Human Interaction Guidelines for iOS)
• Make your UI load fast, so if you can use some build in elements and design patterns from Apple – use them. Keep graphics small first, and scale them if you need to. Make your site look decent, even when the "big" images are still loading. Include loading indicators so people are aware of what they can expect. I always talk about the "Let users imagine what the image will look like" effect before they finally see it. FlipBoard and Reeder do a good job in that.
• On the note of speed: Design transitions and animatics that perform well.
  
• Quite obvious with multiple iPhone version out there: Make your UI responsive. OkCupid does a brilliant job, as well as Netflix iOS – both build in HTML 5.
• On that note, be aware that on the iPad people tend to switch from horizontal to vertical mode.This should be a natural transition.
  
• Make sure you design with contrast. Some people lowered the brightness of their screens immense to save battery life.
• Don't forget the Boot Screen at the beginning. Its a static image.

Well, those are some on top of my head. First one really matters if you are fancy on making it into the app store.

More and more the digital space is moving towards a responsive approach. With Apple updating the iPhone 5 view port re-enforces this direction.

Simply put, there's far to many view-port dimensions these days to be device specific. We could, but we all know budgets allocated for digital strategies and mobile solutions will never bare the load of supporting +147 unique experiences.

With the inclusion of more pixels in an already 'retina' display, we are better to create based on new project including percentage visual creative and development over pixel dimensions.

Utilise the space and be excited by the additional room for content strategy and elements.

Yes, you can use Accessibility features:

• Go to Settings > General > Accessibility
• tap on Larger Text >
• Enable “Larger Accessibility sizes” and set text size

Please notice that this will only be effective on those apps that are set to support Dynamic Types. Then it is normal to see no effect on some of text fields but most of standard apps support this feature.

Also be careful to not set text sizes to too large. This may cause some of text items (like field labels) half cut.

If you have problem reading small texts, another option is to use Zoom feature. Here I described steps for enabling this feature:

Nikoo Shakiba's answer to How can I zoom out on my iPhone?

If you found this answer helpful, please spread the word about our app NikooPlayer on your social media. Thanks for your support.

I was asked to answer this question. I'm a combo interaction/product designer rather than pure UX designer.

First, a word about the background and intention behind the new screen size. My initial impression is that its creation was motivated by political/marketing needs rather than product strategy or use value. The screenshots from the iPhone 5 launch (see in another answer) show how poor has Apple's vision become in the past year. It's awkward. It doesn't speak a modern designer's language. Needless to say, as a designer, the upcoming job of customizing apps for iPhone 5 excited as much as testing for cross-browser compliance used to. A far cry from the excitement over the original iPhone!

Now, it would be very, very different for Apple and for apps if the newly available real estate was to be used not by apps but by the OS - for example, a top nav bar or info bar that would be system-wide. Imagine if in 2000, the Palm Pilot would have added some rows of pixels on top? Certainly it could be used for something meaningful, since apps were sharing the same databases. In the absence of such shared data environment in iOS, I would think third-party data. If I was in Apple, perhaps I would suggest selling this real estate, permanently, to Facebook. This definitely needs tons of discussion and elaboration, and a larger-than-life personality to make the call, but this is the kind of ideas that "stir the pot" in a corporate environment, and that's part of the designer's role. This is what I would do if I was asked what to do with the new screen size - as an Apple designer.

But as this isn't the case (or the question) - let me tackle this from the role of an app designer. I would still try to think of using the space for information and options based on external apps and sources.

If, at this point, my client or boss would stare at me blankly, I would stop discussing strategy and jump to tactics. First, if the app design is not "responsive" already, it's a good occasion to prioritize responsive design in the organization. Look at the meaning of the response: for example, instead of auto-sliding a nav bar from the side (Gmail app) keep it there at all times when in landscape. Or, when you display items on a list, display more items on the list. If the items are meaningful - e.g., calendar events - user is happy. If not, I would discuss with the product people, and if that doesn't work, escalate.

If you have no meaningful content crying to be displayed and no great options asking to be shown at all times (oh dear, isn't the iPhone 5 a penalty for great iPhone 4 design?), I would revisit the product feature list and look for orphan, homeless (i.e., no real estate) ideas and reintroduce them.

As a last resort, I would develop ideas to use this new space with alerts and status messages. That may make my client happy in the shortest time, but will make the iPhone 5 experience feel a bit more like a PC.

Last but not least, this almost begs the return of the awful banner. The size is just perfect. I would not be surprised if, as we speak, mobile ad networks feverishly work on enabling existing apps to use this space and stigmatize the iPhone 5 experience.

If you want the same image to scale based on the size of the browser window, try:

background-image:url('images/back.png');

background-repeat:no-repeat;

background-size:cover;

background-position: center center;

background-attachment: fixed;

Do not set width, height, or margins.

Here’s a great explanation of the technique: Responsive Full Background Image Using CSS

Use UIStackView with vertical alignment, put five UIView’s inside, and put whatever controls you want inside them.

Why wrapping controls in UIView’s? So that we can more easily add spacing, maybe add some background and so on.

You can make all this self-sizing also.

Also, dropdowns, as in dropdown menu are not ios way of doing stuff, at least for iphone. For iPad there is UIPopoverPresentationController.

If you will have variable number of those fields, avoid using table view, stack view deals with insertion pretty easily.

One more thing, this being techical question, you may want to reconsider asking these questions on stack overflow, you will get much more oppinions :)

The User Interface and User Experience guidelines are exactly the same as IPhone 4, however these will help:

Avoid any frequently used or primary controls on the top part of the screen, because when using iPhone 5 with one hand, thumb cannot reach the top part of the screen.

This is exactly the opposite for Left hand users. There is no Data to back this up but this is based on Josh Clark's Tapworthy book where he explains this in detail. Its called the "rule of thumb" Page 58.

Update: Apple's reply to the Thumb Problem:

However,

Buttons like Edit, Search, Refresh, or any other secondary things of a page which will be used less frequently can be placed on the top part. ( This is followed in iPhone 4 as well)

2. App Designs shown in Apple Keynote of Before and After iPhone5:

You don’t just want to make it more big, utilize the more space just like apps did for iPad. Little more features which really takes advantages of the height.

Back Button and co:
Back button on the top left of the Tool bar or Title bar is one of the most used function and is part of core UX of iPhone. Now in iPhone 5 its going to go above the reachable area of the thumb. To solve this problem I would recommend a supplementary gesture control like a swipe left to take back. Eg : Path, Facebook, new Youtube app does this: you don’t have to always tap the menu button at the top-left to see the menu, just swiping left will take you there.
Readability app even goes one step forward by completely removing the back button. When the user taps on any article, the only way of going back is via swiping.

I believe the buttons in the top bar are going to used less frequently and this pattern will be used in most of the apps.

Alert box:
Now the apps need to get access for Contacts, Photos, Location, Push notifications and maybe something else. If your app is going to need more than one of these , please don’t show all in one go as soon as the app starts.
For example Contacts access can be asked only when the user needs to pick a Contact and likewise for the Locations Access.

Will be updated soon with more info ....

There is no effective way to achieve a dynamic drop shadow without affecting performance. An iOS-style drop shadow is usually not much of a shadow at all (i.e., no feathering, blur, or even opacity factors), and is usually just the object itself, drawn with the shadow color, offset a pixel or two below the top object.

This is all how drop-shadow text is drawn, and also how "embossed" text is drawn (text that appears sunken into the UI).

This is actually fairly inexpensive - if you are getting to the point where adding these simple drop shadows makes or breaks your performance, I'd suggest you have bigger optimization fish to fry, or you're trying to do *a lot* all at once.

All of this, of course, goes out of the window if you're trying to do translucent, feathered/blurred shadows, which can get quite expensive.

If you *need* complex shadows to be fast, consider simply prerendering them. For example, if you have a rounded button with a complex drop shadow, create the button (shadows and all) in Photoshop and make it into a stretchable image (9-patch, in Android terms) - iOS has good tools to help you make use of that asset and draw custom button text, images, etc on top - look at the UIButton class and the UIImage class. Rendering images, even tileable or stretchable ones, is quite cheap on iOS. Baking in effects like gradients, shininess, shadows, and accent lines can dramatically improve your performance at the expense of flexibility.

Speaking more generally to constraints:

• Compositing is slow - this really relates to the embedding of views within other views. This will often be necessary regardless, so don't go on an aggressive crusade to weed out all instances of this, but be mindful of it. A lot of views contained within each other will incur a penalty when rendering.
  
• You can eliminate some of the cost of compositing complex view hierarchies by smartly caching. Look at the shouldRasterize property in CALayer for an example of how to do this. Note that caching can become memory-intensive, and if the view is redrawn a lot can actually make it slower than the uncached implementation.
• Transparent things are slow. Wanted something half-transparent with the background subtly showing through? Try not to - or work around it in creative ways (e.g., baking the "background" into an opaque layer instead of actually using transparency).
• Some UI elements are naturally performance intensive - table views and scroll views in particular, since they need to display a *lot* of UI content very quickly. As a designer, be conservative when designing these. A table view where every cell is transparent and subtly blurring the background underneath is not going to perform well even with the best developers working on it. Generally speaking, the more often an object will be refreshed or animated, the more conservative you should be with the design.
• Animations are surprisingly cheap, and easy for developers to implement, these are unlikely to be your performance bottlenecks unless you're trying to do something pretty crazy.
• Limit the amount of off-screen drawing you do. The iPhone 4, for example, has a total GPU fill rate of about 140% of the number of pixels on screen. Which is to say, if you overdraw your screen pixels by over 40%, you are *guaranteed* to miss your 60FPS timeout, and your app will not achieve an optimally smooth framerate. If you are trying to do things in real-time like "blur this image and rotate it by 45 degrees", and you need to do it every frame, you're going to have a bad time making it hit 60 fps.
• Pursuant to the above, but more relevant for developers - if you are doing custom drawing in drawRect, it is a common mistake to redraw the *entire* view. iOS is intelligent enough to request only a redraw of a *part* of a view (say, if it was obscured by another view that has since moved away) - pay attention to the CGRect passed in to drawRect, and if possible only redraw the portion of the UI that has been requested.
• Images are cheap, memory is not as big a problem on iOS as you might suspect. Which is to say, if you want a complex effect that would be unrealistic to achieve in real-time, see if you can bake it into an image somehow. That textured button with the shiny gradient and the beautiful accent lines on top would render a lot faster if you baked all of those effects into a single image.

That's all I can think of right now really. Hit me up if you have more questions.

First, and most obviously, you need to consider the constraints of both platforms. The primary constraint when you are designing an iPhone app is screen size. You have a smaller "canvas" to work with, and that constraint means that you can't overload the UI with an abundancy of controls and information. Not to say that you can "go nuts" when you are designing for the iPad, but you do have some more area to work with... you shouldn't overdo it there, either.

(Another general piece of advice is to get a good understanding of the UI conventions and controls for both devices by studying the iOS Design Guidelines from Apple... so that when you decide to "break" any of these conventions you will at least be able to do so in an informed intelligent way).

Second, if you are building an iPad version of an iPad app, you may want to "reverse engineer" the experience of the iPhone app, to identify what works and what doesn't. What are the core tasks that the app lets the user do? What can be done to enhance or improve these tasks when designing them for the iPad? Test the existing app with users, even if it's just casual "guerrilla testing." You may find that tasks and user needs that work perfectly fine in the mobile context on an iPhone make no sense on the iPad.

Case in point: I design banking and financial service apps, and one of the big new features that all the newer apps are providing is called "Remote Deposit Capture." What is that, you may ask? It's basically the ability to take a photo of a check and deposit it using a mobile banking app. It's universally well regarded by customers and a "delighter"... but it's hardly used on the iPad versions of different mobile banking apps. Why? My theory is it's just easier to take a picture with an iPhone than with an iPad, and the "awkwardness" is reducing usage and perceived value. You may find many features that "make sense" on the iPhone that don't on the iPad.

The opposite is also true, of course... there are going to be some features that don't work in an iPhone app but would work great on an iPad. Any feature that involved "drag-and-drop" as an interaction model, for example.

And for goodness sake, don't use the added screen real estate to add more features and information just because you can! Approach the design of the iPad application with the same discipline you would use when designing a small-screened mobile app. On second thought, use MORE discipline because the temptation will be greater.

Finally, a thought on behavior and context: Many of the best apps on the iPhone are designed to support "quick" behavior - you go in, you do something, you get out. This is because the iPhone is a mobile phone and when people use it they are often... well, mobile. The iPad is a different creature altogether. Though I HAVE seen people walking around city streets using an iPad to do something as they traverse crowds, it's a rare occasion - people do that with iPhones all the time. iPads are used a lot more for "browsing" and so the best apps on that platform provide a simple interface to consumer and interact with content.

Obviously, everyone and every app is different... but you should really look at what people want to do and where they do it first and foremost... no matter what platform you are designing for.

An iOS-style drop shadow is by and large a sorry shadow using any and all means (i.e., no cushioning, dark, or even dimness factors), and is regularly the real article, drawn with the shadow tone, balance a pixel or two under the top thing.

This is altogether sensible - if you are getting straight to the point where adding these fundamental drop shadows addresses the choosing second your show, I'd prescribe you have more noteworthy progression fish to singe, or you're endeavoring to do a lot simultaneously.

The whole of this, clearly, leaves the window on the off chance that you're endeavoring to do clear, cushioned/darkened shadows, which can get quite expensive.

If you need complex shadows to be quick, consider basically prerendering them. For example, if you have a changed catch with an unusual drop shadow, make the catch (shadows and all) in Photoshop and make it into a stretchable picture iOS has extraordinary instruments to assist you with using that asset and draw custom catch text, pictures, etc on top - look at the UIButton class and the UIImage class.

Talking even more generally to restrictions:

Compositing is moderate - this genuinely relates to the embedding of points of view inside alternate points of view. This will oftentimes be indispensable regardless, so don't go on a powerful mission to eliminate all events of this, yet know about it. A lot of points of view contained inside each other will cause a discipline while conveying.

You can execute a part of the cost of compositing complex view chains of significance by distinctly holding. Look at the shouldRasterize property in CALayer for a delineation of how to do this. Note that holding can become memory-heightened, and if the view is redrawn a ton can truly make it more delayed than the uncached execution. Direct things are moderate. Required something half-direct with the establishment inconspicuously showing up on the opposite side? Take the necessary steps not to - or work around it inventively (e.g., setting up the "establishment" into a dim layer as opposed to truly using straightforwardness).

Some UI segments are regularly execution heightened - table viewpoints and material sees explicitly, since they need to show a *lot* of UI content quickly. As an organizer, be conservative when arranging these. A table view where each telephone is clear and unpretentiously darkening the establishment under will not perform well even with the best specialists working on it. When in doubt, the more every now and again an article will be fortified or vivified, the more moderate you should be with the arrangement.

Liveliness is amazingly unobtrusive, and basic for planners to execute, these are likely not going to be your display bottlenecks with the exception of in case you're endeavoring to achieve something pretty crazy.

Yes PDFelement is a good application to add text in the image in iPhone by converting the image using OCR PDF feature. First of all make PDF file of the image then you can easily edit the PDF file using OCR PDF method.

Whether you need to process scanned physical invoices, notes, PDF transcripts or simply convert an image with text to be edited, there is a useful feature you need - OCR PDF.

That means you can convert those scanned images to editable text or scanned documents into editable PDF files.

To know in details about image to text iPhone first of all install PDFelement application on your iPhone and then watch this below shared video in details to get the knowledge about add text in an image on iPhone.

It is not clear if your question pertains to some desktop publishing software (such as InDesign), or on the WEB.

In HTML, wrapping text around an image is achieved as follows:

This is your image:

<img src=”urltoimage.jpg” />

Then after the image you add text.

If you change the style of the image to include:

<img src=”urltoimage.jpg” style=”float: left;” />

Then the text will wrap around the image on the RIGHT side, so the image will ‘float’ on the left side of the text, and text will go around it.

If you change the image to:

<img src=”urltoimage.jpg” style=”float: right;” />

then the text will go around the image on the LEFT.

You can also add margins to give the image a little space:

<img src=”urltoimage.jpg” style=”float: left; margin: 0 10px 10px 0;” />

Notice I only added margin on the RIGHT and BOTTOM of the image, since in this example, text floats around the image on the right.

I hope this helps.

Use Size-Class and add size variation for fonts from Attribute Inspector of Label property.

Here are different possible variations, you can set with Size class:

Try this:

Here is (result) preview of font-size variation, in iPhone and iPad

Update

The result you are expecting, may not be possible using IB (Storyboard) but you can try it with following programmatic solution:

extension UIDevice { 
 
 
    enum DeviceType: String { 
        case iPhone4_4S = "iPhone 4 or iPhone 4S" 
        case iPhones_5_5s_5c_SE = "iPhone 5, iPhone 5s, iPhone 5c or iPhone SE" 
        case iPhones_6_6s_7_8 = "iPhone 6, iPhone 6S, iPhone 7 or iPhone 8" 
        case iPhones_6Plus_6sPlus_7Plus_8Plus = "iPhone 6 Plus, iPhone 6S Plus, iPhone 7 Plus or iPhone 8 Plus" 
        case iPhoneX = "iPhone X" 
        case unknown = "iPadOrUnknown" 
    } 
 
    var deviceType: DeviceType { 
        switch UIScreen.main.nativeBounds.height { 
        case 960: 
            return .iPhone4_4S 
        case 1136: 
            return .iPhones_5_5s_5c_SE 
        case 1334: 
            return .iPhones_6_6s_7_8 
        case 1920, 2208: 
            return .iPhones_6Plus_6sPlus_7Plus_8Plus 
        case 2436: 
            return .iPhoneX 
        default: 
            return .unknown 
        } 
    } 
} 
 
 
// Get device type (with help of above extension) and assign font size accordingly. 
let label = UILabel() 
 
let deviceType = UIDevice.current.deviceType 
 
switch deviceType { 
 
case .iPhone4_4S: 
    label.font = UIFont.systemFont(ofSize: 10) 
 
case .iPhones_5_5s_5c_SE: 
    label.font = UIFont.systemFont(ofSize: 12) 
 
case .iPhones_6_6s_7_8: 
    label.font = UIFont.systemFont(ofSize: 14) 
 
case .iPhones_6Plus_6sPlus_7Plus_8Plus: 
    label.font = UIFont.systemFont(ofSize: 16) 
 
case .iPhoneX: 
    label.font = UIFont.systemFont(ofSize: 18) 
 
default: 
    print("iPad or Unkown device") 
    label.font = UIFont.systemFont(ofSize: 20) 
 
} 

Q:How do I make text wrap around an image?

A: Well, see the tags of the question, "A"-thing, hehehe, "A" thing promo????

(may be not a coder’s question)

InDesign User Guide

Coder’s Question !!!!

XAML

Wrapping text around an image or linking two TextBlocks in C# WPF

See, I did not hide the title bar, it is XAML, really.

There are third party keyboards that can do this feature but the features “ slide to type” comes standard on iOS 13

Btw this post was typed with the feature on iOS 13 beta 1

Isn’t it cool!

I feel that it's a result of that Oh-it's-there-so-I-have-to-use-it mentality.

We always look it this way before we consider supporting landscape for anything: Is there a justification for the user to do so and is there justification for the app to do so?

If either answer come up as a "no"... We don't bother.

Cause when it's broken down, the user needs to stop what they are doing, rotate the device, wait a few seconds till the device realizes it's rotated now, and then have the app adjust itself.

This a interruptive and time consuming thing for both the user and the app.

Why make the user wait for something they don't need, or why burden yourself supporting something the user doesn't need.

iPhones and Apple products use a service called iMessage. iMessage is one of the features exclusive to Apple devices, with features like being able to Apple Pay money to other people, having sent and read markings, and sending fun doodles. Apple devices will always look blue in iMessage.

If you get a green bubble it means the message was sent in SMS, usually from Androids but could also be from flip phones or other dumb phones. Androids do not use iMessage because iMessage is exclusive to the Apple ecosystem. Because of this, you cannot use many iMessage features with somebody with a green bubble. On the Android side, iMessage isn't even a thing, so not only will messages on Android be all sorts of colors depending on the contact color, but if you receive a message from an iPhone it will be sent via SMS.

An initial search for what was globally recognizable as a filter icon, and the most common representation of it in most glyph icon sets was this:

This is pretty clear visually - a large number of results, being refined or funneled into a thinner stream of information. In the context of an iPhone app, there are other factors to consider:
- How are your filter options going to display? It would be helpful if your filter icon indicated in some way to the user how the options were going to transition in to the screen.
- The number of filter options you're going to have - will they fit in a menu, or do they need their own screen, etc
- What size is your filter icon going to be? It needs to be a distinguishable shape at the size you choose, with enough actionable area
- How will you indicate to the user that their results are currently being filtered?
How will they reset? etc.

-- TL;DR - this sort of turned into a 'History of the filter function in Pointshelf', but in here is an evolution of the filter icon through its different versions --

While working on the initial UX for Pointshelf (a mobile loyalty platform), filtering was a very important function and it was imperative that it be clear and intuitive. After experimenting with a few options, we decided the best course of action was to have the filters as a drop down menu with individual switches. For this version (iOS 6), these were some of the initial ideas floated for a Filter menu button placed at the top-right.

One obvious way to do it was to place a button with the text "Filter" on it, as many apps were doing, and then changing it to an icon later once users had grown accustomed to it. Other options were perhaps a Gear icon, indicative of settings; or a Menu icon - but since this was neither, it was simply a Filter menu, it didn't make sense to use these.

The first version of Pointshelf released with this icon indicating filters. This turned out to be slightly jarring though, as when you clicked a downward arrow, you'd expect the menu to slide out right where it was. So for a subsequent release we rearranged the navigation slightly, and made the Filters dropdown from the top and slide back in.

The next version shifted all primary functions into a sidebar, as more features were added - including all the Filter options as one section of the sidebar menu.

As of now, the sidebar approach works pretty effectively. Newer apps are getting more experimental with their UI, esp with iOS 7, so filters could maybe be hover buttons over your content like airBnb:

or when your Search bar comes into focus, the filters can automatically populate the screen like Google maps - and you bypass the Filter icon entirely: